Genom hela boken har vi introducerat dussintals Git‑kommandon och försökt presentera dem i en berättande form, där vi långsamt lägger till fler kommandon. Det gör dock att exempel på hur kommandona används är något utspridda genom hela boken.
I detta appendix går vi igenom alla Git‑kommandon vi tog upp i boken, grovt grupperade efter vad de används till. Vi berättar om vad varje kommando gör på en övergripande nivå och pekar sedan ut var i boken du hittar oss när vi använder det.
|
Tip
|
Du kan förkorta långa flaggor.
Till exempel kan du skriva |
Det finns två kommandon som används ganska ofta, från de första anropen av Git till vardaglig justering och referenshantering: config och help.
Git har ett standardsätt att göra hundratals saker. För många av dessa kan du säga åt Git att som standard göra dem på ett annat sätt, eller ställa in dina efter dina val. Här anger du allt från ditt namn till terminalfärgpreferenser eller vilken redigerare du använder. Det finns flera filer som detta kommando läser från och skriver till, så att du kan sätta värden globalt eller för specifika kodförråd.
Kommandot git config används i nästan varje kapitel i boken.
I ch01-getting-started.asc använde vi det för att ange vårt namn, e‑postadress och redigerarpreferens innan vi ens började använda Git.
I ch02-git-basics-chapter.asc visade vi hur du kunde använda det för att skapa kortkommandon som expanderar till långa flaggsekvenser så att du slipper skriva dem varje gång.
I ch03-git-branching.asc använde vi det för att sätta --rebase till standard när du kör git pull.
I ch07-git-tools.asc använde vi det för att sätta upp en standardlagring för dina HTTP‑lösenord.
I ch08-customizing-git.asc visade vi hur man sätter upp smudge‑ och clean‑filter för innehåll som går in och ut ur Git.
Slutligen är i princip hela ch08-customizing-git.asc ägnat åt kommandot.
Som komplement till konfigurationsinstruktionerna i ch01-getting-started.asc kan många redigerare sättas så här:
core.editor‑konfigurationskommandon
| Redigerare | Konfigurationskommando |
|---|---|
Atom |
|
BBEdit (macOS, med kommandoradsverktyg) |
|
Emacs |
|
Gedit (Linux) |
|
Gvim (Windows 64-bitars) |
|
Helix |
|
Kate (Linux) |
|
nano |
|
Notepad (Windows 64-bitars) |
|
Notepad++ (Windows 64-bitars) |
|
Scratch (Linux) |
|
Sublime Text (macOS) |
|
Sublime Text (Windows 64-bitars) |
|
TextEdit (macOS) |
|
Textmate |
|
Textpad (Windows 64-bitars) |
|
UltraEdit (Windows 64-bitars) |
|
Vim |
|
Visual Studio Code |
|
VSCodium (fria/libre-öppna källkodsbinärer av VSCode) |
|
WordPad |
|
Xi |
|
|
Note
|
Om du har en 32‑bitars redigerare på ett Windows‑system med 64‑bitars arkitektur installeras programmet i |
Kommandot git help används för att visa all dokumentation som följer med Git för vilket kommando som helst.
Även om vi ger en grovöversikt av de flesta populära här i appendixet så kan du alltid köra git help <command> för en fullständig lista över alla möjliga alternativ och flaggor för varje kommando.
Vi introducerade kommandot git help i ch01-getting-started.asc och visade hur man använder det för att hitta mer information om git shell i ch04-git-on-the-server.asc.
Det finns två sätt att skaffa ett Git‑kodförråd på. Det ena är att kopiera det från ett befintligt kodförråd på nätverket eller någon annanstans, och det andra är att skapa ett nytt i en befintlig katalog.
För att ta en katalog och göra den till ett nytt Git‑kodförråd så att du kan börja versionshantera den kan du helt enkelt köra git init.
Vi introducerar detta först i ch02-git-basics-chapter.asc, där vi visar hur man skapar ett helt nytt kodförråd att börja arbeta i.
Vi nämner kort hur du kan ändra standardgrennamnet från “master” i ch03-git-branching.asc.
Vi använder kommandot för att skapa ett tomt bart kodförråd för en server i ch04-git-on-the-server.asc.
Slutligen går vi igenom några detaljer om vad det egentligen gör bakom kulisserna i ch10-git-internals.asc.
Kommandot git clone är i praktiken ett omslag kring flera andra kommandon.
Det skapar en ny katalog, går in i den och kör git init för att göra den till ett tomt Git‑kodförråd, lägger till ett fjärrkodförråd (git remote add) med den URL du skickar in (som standard kallad origin), kör git fetch från fjärrkodförrådet och växlar sedan in den senaste incheckningen i din arbetskatalog med git checkout.
Kommandot git clone används på dussintals ställen i boken, men vi listar bara några intressanta ställen.
Det introduceras och förklaras i ch02-git-basics-chapter.asc, där vi går igenom några exempel.
I ch04-git-on-the-server.asc tittar vi på att använda alternativet --bare för att skapa en kopia av ett Git‑kodförråd utan arbetskatalog.
I ch07-git-tools.asc använder vi det för att packa upp en Git‑bunt.
Slutligen lär vi oss flaggan --recurse-submodules i ch07-git-tools.asc för att göra det lite enklare att klona ett kodförråd med submoduler.
Även om det används på många andra ställen i boken så är de här de som är något mer unika, eller där de används på ett lite annorlunda sätt.
För det grundläggande arbetsflödet att köa innehåll och checka in det i din historik finns det bara några grundläggande kommandon.
Kommandot git add lägger till innehåll från arbetskatalogen till köytan (staging eller “index”) för nästa incheckning.
När kommandot git commit körs tittar det som standard bara på denna köyta, så git add används för att utforma hur den nästa ögonblicksbilden ska se ut.
Detta kommando är otroligt viktigt i Git och nämns eller används dussintals gånger i boken. Vi går snabbt igenom några av de mer unika användningarna.
Vi introducerar och förklarar git add i detalj i ch02-git-basics-chapter.asc.
Vi nämner hur man använder det för att lösa sammanslagningskonflikter i ch03-git-branching.asc.
Vi går igenom hur man använder det för att interaktivt köa bara vissa delar av en ändrad fil i ch07-git-tools.asc.
Slutligen emulerar vi det på lågnivå i ch10-git-internals.asc, så att du kan få en uppfattning om vad det gör bakom kulisserna.
Kommandot git status visar de olika tillstånden för filer i din arbetskatalog och din köyta.
Det visar vilka filer som är ändrade och oköade och vilka som är köade men ännu inte checkade in.
I normal form visar det också några grundläggande tips om hur man flyttar filer mellan dessa lägen.
Vi tar upp status första gången i ch02-git-basics-chapter.asc, både i dess grundläggande och förenklade former.
Även om vi använder det genom hela boken täcks i princip allt du kan göra med kommandot git status där.
Kommandot git diff används när du vill se skillnader mellan två träd.
Det kan vara skillnaden mellan din arbetsmiljö och din köyta (git diff i sig), mellan köytan och din senaste incheckning (git diff --staged), eller mellan två incheckningar (git diff master branchB).
Vi tittar först på grundläggande användning av git diff i ch02-git-basics-chapter.asc, där vi visar hur man ser vilka ändringar som är köade och vilka som ännu inte är det.
Vi använder det för att leta efter möjliga blankteckensproblem före incheckning med alternativet --check i ch05-distributed-git.asc.
Vi ser hur man kontrollerar skillnaderna mellan grenar mer effektivt med syntaxen git diff A…B i ch05-distributed-git.asc.
Vi använder det för att filtrera bort blankteckensskillnader med -b och för att jämföra olika stadier av konfliktfiler med --theirs, --ours och --base i ch07-git-tools.asc.
Slutligen använder vi det för att jämföra submoduländringar effektivt med --submodule i ch07-git-tools.asc.
Kommandot git difftool startar helt enkelt ett externt verktyg för att visa skillnaden mellan två träd om du vill använda något annat än det inbyggda git diff‑kommandot.
Vi nämner detta bara kort i ch02-git-basics-chapter.asc.
Kommandot git commit tar allt filinnehåll som har köats med git add, registrerar en ny permanent ögonblicksbild i databasen och flyttar sedan grenpekaren på den aktuella grenen till den.
Vi går först igenom grunderna i att checka in i ch02-git-basics-chapter.asc.
Där visar vi också hur man använder flaggan -a för att hoppa över steget git add i dagliga arbetsflöden och hur man använder flaggan -m för att ange ett incheckningsmeddelande på kommandoraden i stället för att starta en redigerare.
I ch02-git-basics-chapter.asc tar vi upp hur man använder alternativet --amend för att göra om den senaste incheckningen.
I ch03-git-branching.asc går vi igenom i mycket större detalj vad git commit gör och varför det gör det på det sättet.
Vi tittade på hur man signerar incheckningar kryptografiskt med flaggan -S i ch07-git-tools.asc.
Slutligen tittar vi på vad kommandot git commit gör i bakgrunden och hur det egentligen är implementerat i ch10-git-internals.asc.
Kommandot git reset används främst för att ångra saker, vilket du säkert kan gissa av verbet.
Det flyttar runt HEAD‑pekaren och kan valfritt ändra index eller köytan, och kan också valfritt ändra arbetskatalogen om du använder --hard.
Det sista alternativet gör att kommandot kan radera ditt arbete om det används fel, så se till att du förstår det innan du använder det.
Vi visar först hur git reset enklast används i ch02-git-basics-chapter.asc, där vi använder det för att avköa en fil vi hade kört git add på.
Vi går sedan igenom det i ganska stor detalj i ch07-git-tools.asc, som helt ägnas åt att förklara kommandot.
Vi använder git reset --hard för att avbryta en sammanslagning i ch07-git-tools.asc, där vi också använder git merge --abort, vilket är ett slags omslag för kommandot git reset.
Kommandot git rm används för att ta bort filer från köytan och arbetskatalogen i Git.
Det liknar git add i det att det köar en fil för borttagning inför nästa incheckning.
Vi går igenom kommandot git rm i detalj i ch02-git-basics-chapter.asc, inklusive att ta bort filer rekursivt och att bara ta bort filer från köytan men lämna dem i arbetskatalogen med --cached.
Det enda andra avvikande användningsfallet för git rm i boken är i ch10-git-internals.asc där vi kort använder och förklarar --ignore-unmatch när vi kör git filter-branch, vilket helt enkelt gör att det inte ger fel när filen vi försöker ta bort inte finns.
Detta kan vara användbart för skriptändamål.
Kommandot git mv är ett tunt bekvämlighetskommando för att flytta en fil och sedan köra git add på den nya filen och git rm på den gamla filen.
Vi nämner detta kommando bara kort i ch02-git-basics-chapter.asc.
Kommandot git clean används för att ta bort oönskade filer från din arbetskatalog.
Det kan till exempel innebära att ta bort temporära byggartefakter eller filer efter sammanslagningskonflikter.
Vi täcker många av alternativen och scenarierna där du kan använda kommandot clean i ch07-git-tools.asc.
Det finns bara en handfull kommandon som implementerar det mesta av grening och sammanslagning i Git.
Kommandot git branch är i praktiken ett verktyg för grenhantering.
Det kan lista de grenar du har, skapa en ny gren, ta bort grenar och byta namn på grenar.
Merparten av ch03-git-branching.asc är ägnat åt kommandot branch och det används genom hela kapitlet.
Vi introducerar det först i ch03-git-branching.asc och går igenom de flesta andra funktionerna (lista och ta bort) i ch03-git-branching.asc.
I ch03-git-branching.asc använder vi alternativet git branch -u för att sätta upp en spårningsgren.
Slutligen går vi igenom lite av vad det gör i bakgrunden i ch10-git-internals.asc.
Kommandot git checkout används för att växla grenar och lägga ut innehåll i din arbetskatalog.
Vi stöter först på kommandot i ch03-git-branching.asc tillsammans med kommandot git branch.
Vi ser hur man använder det för att börja spåra grenar med flaggan --track i ch03-git-branching.asc.
Vi använder det för att återinföra filkonflikter med --conflict=diff3 i ch07-git-tools.asc.
Vi går igenom dess relation till git reset i större detalj i ch07-git-tools.asc.
Slutligen går vi in på implementationen i ch10-git-internals.asc.
Verktyget git merge används för att sammanfoga en eller flera grenar i grenen du har växlad till.
Det flyttar sedan fram den aktuella grenen till resultatet av sammanslagningen.
Kommandot git merge introducerades först i ch03-git-branching.asc.
Även om det används på olika ställen i boken finns det väldigt få variationer av kommandot – i regel bara git merge <branch> med namnet på den enskilda gren du vill sammanfoga in.
Vi gick igenom hur man gör en pressad sammanslagning (där Git sammanfogar arbetet men låtsas att det bara är en ny incheckning utan att registrera historiken för grenen du sammanfogar) i slutet av ch05-distributed-git.asc.
Vi gick igenom mycket om sammanslagningsprocessen och kommandot, inklusive alternativet -Xignore-space-change och flaggan --abort för att avbryta en problematisk sammanslagning i ch07-git-tools.asc.
Vi lärde oss hur man verifierar signaturer före sammanslagning om ditt projekt använder GPG‑signering i ch07-git-tools.asc.
Slutligen lärde vi oss om subtree‑sammanslagning i ch07-git-tools.asc.
Kommandot git mergetool startar helt enkelt en extern sammanslagningshjälpare om du får problem med en sammanslagning i Git.
Vi nämner det snabbt i ch03-git-branching.asc och går på djupet om hur man implementerar ett eget externt sammanslagningsverktyg i ch08-customizing-git.asc.
Kommandot git log används för att visa den nåbara historiken i ett projekt, från den senaste incheckningsögonblicksbilden och bakåt.
Som standard visar det bara historiken för grenen du står på, men det kan få andra eller till och med flera huvuden eller grenar att traversera.
Det används också ofta för att visa skillnader mellan två eller fler grenar på incheckningsnivå.
Detta kommando används i nästan varje kapitel i boken för att demonstrera historiken i ett projekt.
Vi introducerar kommandot och går igenom det i viss detalj i ch02-git-basics-chapter.asc.
Där tittar vi på alternativen -p och --stat för att få en uppfattning om vad som introducerades i varje incheckning, och flaggan --pretty och --oneline för att visa historiken mer koncist, tillsammans med några enkla filter för datum och författare.
I ch03-git-branching.asc använder vi det med flaggan --decorate för att enkelt visualisera var våra grenpekare ligger och vi använder också flaggan --graph för att se hur divergerande historiker ser ut.
I ch05-distributed-git.asc och ch07-git-tools.asc går vi igenom syntaxen branchA..branchB för att använda kommandot git log och se vilka incheckningar som är unika för en gren jämfört med en annan gren.
I ch07-git-tools.asc går vi igenom detta ganska ingående.
I ch07-git-tools.asc och ch07-git-tools.asc går vi igenom formatet branchA…branchB och syntaxen --left-right för att se vad som finns i den ena grenen eller den andra men inte i båda.
I ch07-git-tools.asc tittar vi också på hur man använder alternativet --merge för att hjälpa till med felsökning av sammanslagningskonflikter samt hur man använder --cc för att titta på sammanslagningsincheckningskonflikter i historiken.
I ch07-git-tools.asc använder vi alternativet -g för att visa Git‑refloggen genom verktyget i stället för att traversera grenar.
I ch07-git-tools.asc tittar vi på att använda alternativen -S och -L för att göra ganska avancerade sökningar efter något som hände historiskt i koden, såsom att se historiken för en funktion.
I ch07-git-tools.asc ser vi hur man använder --show-signature för att lägga till en valideringssträng till varje incheckning i git log‑utdata utifrån om den var giltigt signerad eller inte.
Kommandot git stash används för att tillfälligt lagra oincheckat arbete för att rensa din arbetskatalog utan att behöva checka in ofärdigt arbete på en separat gren.
Detta täcks i princip helt i ch07-git-tools.asc.
Kommandot git tag används för att ge ett permanent bokmärke till en specifik punkt i kodhistoriken.
Det används i regel för utgåvor.
Kommandot introduceras och täcks i detalj i ch02-git-basics-chapter.asc och vi använder det i praktiken i ch05-distributed-git.asc.
Vi täcker också hur man skapar en GPG‑signerad tagg med flaggan -s och hur man verifierar en med flaggan -v i ch07-git-tools.asc.
Det finns inte särskilt många kommandon i Git som går ut på nätet; nästan alla arbetar mot den lokala databasen. När du är redo att dela ditt arbete eller uppdatera ändringar från någon annanstans finns det bara en handfull kommandon som hanterar fjärrkodförråd.
Kommandot git fetch kommunicerar med ett fjärrkodförråd och uppdaterar ditt akutella kodförråd med all information som finns i det kodförrådet, och lagrar den i din lokala databas.
Vi tittar först på kommandot i ch02-git-basics-chapter.asc och fortsätter att se användningsexempel i ch03-git-branching.asc.
Vi använder det också i flera av exemplen i ch05-distributed-git.asc.
Vi använder det för att uppdatera en enda specifik referens som ligger utanför standardutrymmet i ch06-github.asc och vi ser hur man uppdaterar från en bunt i ch07-git-tools.asc.
Vi sätter upp mycket anpassade refspecar för att få git fetch att göra något lite annorlunda än standarden i ch10-git-internals.asc.
Kommandot git pull kombinerar i grunden git fetch och git merge, där Git uppdaterar från fjärrkodförrådet du anger och sedan omedelbart försöker sammanfoga det i grenen du står på.
Vi introducerar det kort i ch02-git-basics-chapter.asc och visar hur man ser vad det kommer att sammanfoga om du kör det i ch02-git-basics-chapter.asc.
Vi ser också hur man använder det för att hjälpa till med ombaseringsproblem i ch03-git-branching.asc.
Vi visar hur man använder det med en URL för att dra in ändringar i en engångsoperation i ch05-distributed-git.asc.
Slutligen nämner vi mycket kort att du kan använda flaggan --verify-signatures för att verifiera att incheckningar du uppdaterar har GPG‑signerats i ch07-git-tools.asc.
Kommandot git push används för att kommunicera med ett annat kodförråd, att beräkna vad din lokala databas har som fjärrkodförrådet inte har och sedan skicka skillnaden.
Det kräver skrivåtkomst till det andra kodförrådet och autentiseras därför normalt på något sätt.
Vi tittar först på kommandot git push i ch02-git-basics-chapter.asc.
Där täcker vi grunderna i att skicka en gren till ett fjärrkodförråd.
I ch03-git-branching.asc går vi lite djupare i att skicka specifika grenar och i ch03-git-branching.asc ser vi hur man sätter upp spårningsgrenar för att automatiskt skicka till.
I ch03-git-branching.asc använder vi flaggan --delete för att ta bort en gren på servern med git push.
Genom hela ch05-distributed-git.asc ser vi flera exempel på hur man använder git push för att dela arbete på grenar via flera fjärrkodförråd.
Vi ser hur man använder det för att dela taggar som du har skapat med flaggan --tags i ch02-git-basics-chapter.asc.
I ch07-git-tools.asc använder vi flaggan --recurse-submodules för att kontrollera att allt arbete i våra submoduler har publicerats innan vi skickar upp superprojektet, vilket kan vara mycket användbart när man använder submoduler.
I ch08-customizing-git.asc pratar vi kort om kroken pre-push, som är ett skript vi kan sätta upp för att köras innan en uppskickning slutförs för att verifiera att den ska tillåtas.
Slutligen tittar vi i ch10-git-internals.asc på att skicka med en full refspec i stället för de allmänna genvägar som normalt används. Det kan hjälpa dig att vara väldigt specifik med vilket arbete du vill dela.
Kommandot git remote är ett hanteringsverktyg för att visa dina fjärrkodförråd.
Det låter dig spara långa URL:er som korta handtag, som “origin”, så att du slipper skriva om dem hela tiden.
Du kan ha flera sådana och kommandot git remote används för att lägga till, ändra och ta bort dem.
Detta kommando täcks i detalj i ch02-git-basics-chapter.asc, inklusive att lista, lägga till, ta bort och byta namn på dem.
Det används i nästan varje efterföljande kapitel i boken också, men alltid i standardformatet git remote add <name> <url>.
Kommandot git archive används för att skapa en arkivfil av en specifik ögonblicksbild av projektet.
Vi använder git archive för att skapa en tar‑fil av ett projekt för delning i ch05-distributed-git.asc.
Kommandot git submodule används för att hantera externa kodförråd inuti ett vanligt kodförråd.
Det kan handla om bibliotek eller andra typer av delade resurser.
Kommandot submodule har flera underkommandon (add, update, sync etc.) för att hantera dessa resurser.
Detta kommando nämns bara och täcks helt i ch07-git-tools.asc.
Kommandot git show kan visa ett Git‑objekt på ett enkelt och läsbart sätt.
Normalt använder du det för att visa information om en tagg eller en incheckning.
Vi använder det först för att visa information om annoterade taggar i ch02-git-basics-chapter.asc.
Senare använder vi det ganska mycket i ch07-git-tools.asc för att visa de incheckningar som våra olika revisionsval löses till.
En av de mer intressanta sakerna vi gör med git show är i ch07-git-tools.asc för att extrahera specifika filinnehåll från olika stadier under en sammanslagningskonflikt.
Kommandot git shortlog används för att sammanfatta utdata från git log.
Det tar många av samma alternativ som git log, men i stället för att lista alla incheckningar presenterar det en sammanfattning av incheckningarna grupperade efter författare.
Vi visade hur man använder det för att skapa en snygg ändringslogg i ch05-distributed-git.asc.
Kommandot git describe tar något som kan lösas till en incheckning och producerar en sträng som är någorlunda mänskligt läsbar och stabil över tid.
Det är ett sätt att beskriva en incheckning lika entydigt som en inchecknings‑SHA‑1 men mer lättläst.
Vi använder git describe i ch05-distributed-git.asc och ch05-distributed-git.asc för att få en sträng att namnge vår utgåvefil efter.
Git har ett par kommandon för att felsöka problem i din kod. Det sträcker sig från att ta reda på var något introducerades till att ta reda på vem som gjorde det.
Med verktyget git bisect hittar du vilken specifik incheckning som först introducerade ett programfel genom automatisk bisektering.
Det täcks helt i ch07-git-tools.asc och nämns bara där.
Kommandot git blame visar för varje rad i en fil vilken incheckning som senast ändrade raden och vem som skrev den.
Det hjälper dig hitta personen du ska fråga om mer information om en specifik del av din kod.
Det täcks i ch07-git-tools.asc och nämns bara där.
Kommandot git grep hjälper dig att hitta en sträng eller ett reguljärt uttryck i vilken fil som helst i din källkod, även äldre versioner av ditt projekt.
Det täcks i ch07-git-tools.asc och nämns bara där.
Några kommandon i Git kretsar kring konceptet att tänka på incheckningar utifrån de ändringar de introducerar, som om incheckningsserien vore en serie patchar. Dessa kommandon hjälper dig att hantera dina grenar på detta sätt.
Kommandot git cherry-pick används för att ta ändringen som introducerats i en enskild Git‑incheckning och försöka återinföra den som en ny incheckning på grenen du står på.
Så kan du bara ta en eller två incheckningar från en gren i stället för att sammanfoga in grenen som tar med alla ändringar.
Handplockning beskrivs och demonstreras i ch05-distributed-git.asc.
Kommandot git rebase är i princip en automatiserad handplockning.
Det bestämmer en serie incheckningar och handplockar dem en efter en i samma ordning någon annanstans.
Ombasering täcks i detalj i ch03-git-branching.asc, inklusive de samarbetsproblem som uppstår när man ombaserar grenar som redan är offentliga.
Vi använder det i praktiken under ett exempel på att dela upp historiken i två separata kodförråd i ch07-git-tools.asc, och använder även flaggan --onto.
Vi går igenom att stöta på en sammanslagningskonflikt under ombasering i ch07-git-tools.asc.
Vi använder det också i ett interaktivt skriptläge med alternativet -i i ch07-git-tools.asc.
Kommandot git revert är i praktiken ett omvänt git cherry-pick.
Det skapar en ny incheckning som tillämpar exakt motsatsen till ändringen som introducerades i incheckningen du riktar in dig på, vilket i praktiken ångrar den.
Vi använder detta i ch07-git-tools.asc för att ångra en sammanslagningsincheckning.
Många Git‑projekt, inklusive Git självt, förvaltas helt via e‑postlistor. Git har flera verktyg inbyggda för att underlätta denna process, från att generera patchar som du enkelt kan e‑posta till att tillämpa dessa patchar från en e‑postlåda.
Kommandot git apply tillämpar en patch skapad med git diff eller GNU diff‑kommandot.
Det liknar vad kommandot patch gör, men med några små skillnader.
Vi demonstrerar hur man använder det och under vilka omständigheter man kan göra det i ch05-distributed-git.asc.
Kommandot git am används för att tillämpa patchar från en e‑postinkorg, specifikt en som är mbox‑formaterad.
Det är användbart för att ta emot patchar via e‑post och tillämpa dem på ditt projekt enkelt.
Vi täckte användning och arbetsflöde kring git am i ch05-distributed-git.asc, inklusive flaggorna --resolved, -i och -3.
Det finns också flera krokar du kan använda för att hjälpa till med arbetsflödet kring git am, och de täcks alla i ch08-customizing-git.asc.
Vi använder det också för att tillämpa patch‑formaterade GitHub‑ändringsförfrågningar i ch06-github.asc.
Kommandot git format-patch används för att generera en serie patchar i mbox‑format som du kan använda för att skicka till en e‑postlista korrekt formaterade.
Vi går igenom ett exempel på att bidra till ett projekt med verktyget git format-patch i ch05-distributed-git.asc.
Kommandot git imap-send laddar upp en postlåda som genererats med git format-patch till en IMAP‑utkastmapp.
Vi går igenom ett exempel på att bidra till ett projekt genom att skicka patchar med verktyget git imap-send i ch05-distributed-git.asc.
Kommandot git send-email används för att skicka patchar som genereras med git format-patch via e‑postmeddelanden.
Vi går igenom ett exempel på att bidra till ett projekt genom att skicka patchar med verktyget git send-email i ch05-distributed-git.asc.
Kommandot git request-pull används helt enkelt för att generera en exempeltext att e‑posta till någon.
Om du har en gren på en publik server och vill låta någon veta hur de kan integrera dessa ändringar utan att skicka patcharna via e‑post kan du köra detta kommando och skicka utdata till personen du vill ska uppdatera ändringarna.
Vi demonstrerar hur man använder git request-pull för att generera ett ändringsförfråganmeddelande i ch05-distributed-git.asc.
Git kommer med några kommandon för att integrera med andra versionshanteringssystem.
Kommandot git svn används för att kommunicera med versionshanteringssystemet Subversion som klient.
Det betyder att du kan använda Git för att uppdatera från och checka in till en Subversion‑server.
Detta kommando täcks på djupet i ch09-git-and-other-systems.asc.
För andra versionshanteringssystem eller import från nästan vilket format som helst kan du använda git fast-import för att snabbt koppla det andra formatet till något Git enkelt kan registrera.
Detta kommando täcks på djupet i ch09-git-and-other-systems.asc.
Om du administrerar ett Git‑kodförråd eller behöver fixa något rejält erbjuder Git flera administrativa kommandon för att hjälpa dig.
Kommandot git gc kör “skräpinsamling” på ditt kodförråd, tar bort onödiga filer i databasen och packar ihop de återstående filerna i ett mer effektivt format.
Detta kommando körs normalt i bakgrunden åt dig, men du kan köra det manuellt om du vill. Vi går igenom några exempel på detta i ch10-git-internals.asc.
Kommandot git fsck används för att kontrollera den interna databasen efter fel eller inkonsekvenser.
Vi använder det bara snabbt en gång i ch10-git-internals.asc för att söka efter hängande objekt.
Kommandot git reflog går igenom en logg över var alla grenhuvuden har varit medan du arbetar, för att hitta incheckningar som kan ha gått förlorade när historik skrivs om.
Vi täcker kommandot främst i ch07-git-tools.asc, där vi visar normal användning och hur man använder git log -g för att se samma information med git log‑utdata.
Vi går också igenom ett praktiskt exempel på att återställa en sådan förlorad gren i ch10-git-internals.asc.
Kommandot git filter-branch används för att skriva om många incheckningar enligt vissa mönster, som att ta bort en fil överallt eller filtrera hela kodförrådet till en enda underkatalog för att extrahera ett projekt.
I ch07-git-tools.asc förklarar vi kommandot och utforskar flera olika alternativ som --commit-filter, --subdirectory-filter och --tree-filter.
I ch09-git-and-other-systems.asc använder vi det för att städa upp importerade externa kodförråd.
Vi stötte också på många lågnivåkommandon i boken.
Det första vi stöter på är ls-remote i ch06-github.asc som vi använder för att titta på de råa referenserna på servern.
Vi använder ls-files i ch07-git-tools.asc, ch07-git-tools.asc och ch07-git-tools.asc för att ta en mer rå titt på hur din köyta ser ut.
Vi nämner också rev-parse i ch07-git-tools.asc för att ta nästan vilken sträng som helst och göra om den till en objekts‑SHA‑1.
De flesta lågnivåkommandon vi tar upp finns dock i ch10-git-internals.asc, vilket i stort sett är vad kapitlet fokuserar på. Vi försökte undvika att använda dem genom större delen av resten av boken.