Du arbetar glatt med något och upptäcker att ändringarna i dessa filer är i god ordning. Du vill inte se dem när du kör git diff, eftersom du planerar att arbeta med andra filer och ändringar med dessa filer är störande.

Någon begär en hämtning ("pull"), och ändringarna verkar värda att sammanslås.

Indexet har dock redan smutsats ned (d.v.s. indexet matchar inte HEAD-incheckningen). Men om det är känt att den pull som ska göras inte påverkar frotz.c eller filfre.c, återställs indexändringarna för dessa två filer. Ändringarna i arbetsträdet finns kvar där.

Sedan kan hämtning och sammanslagning göras, och ändringarna i frotz.c och filfre.c kvar i arbetsträdet.

Det görs oftast när det visar sig att det som just checkades in är ofullständigt, eller att incheckningsmeddelandet stavades fel, eller båda. Lämnar arbetsträdet som det var före "återställning".

Gör korrigeringar till arbetsträds-filer.

"reset" kopierar den gamla huvudet till .git/ORIG_HEAD; gör om incheckningen genom att börja med dess loggmeddelande. Om du inte behöver redigera meddelandet ytterligare kan du ge alternativet -C i stället.

Du har gjort några incheckningar, men inser att det var för tidigt att lägga dem i master-grenen. Du vill fortsätta finslipa dem i en ämnes-gren, så skapa en topic/wip-gren från den nuvarande HEAD.

Spola tillbaka master-grenen för att bli av med de tre incheckningarna.

Byt till grenen topic/wip och fortsätt arbeta.

De tre senaste incheckningarna (HEAD, HEAD^ och HEAD~2) var dåliga och du vill inte se dem igen. Gör inte detta om du redan har gett dessa incheckningar till någon annan. (Se avsnittet "ÅTERSTÄLLA FRÅN UPSTRÖMSREBASE" i git-rebase[1] för konsekvenserna av att göra det.)

Att försöka uppdatera uppströms resulterade i många konflikter; du var inte redo att lägga ner mycket tid på att sammanslå just nu, så du bestämmer dig för att göra det senare.

"pull" har inte gjort sammanslagningsincheckning, så git reset --hard som är en synonym för git reset --hard HEAD rensar bort röran från indexfilen och arbetsträdet.

Sammanfoga en ämnesgren med den aktuella grenen, vilket resulterade i en snabbspolning.

Men det står klart att ämnesgrenen ännu inte är redo för offentlig konsumtion än. "pull" eller "merge" lämnar alltid den ursprungliga toppen på den aktuella grenen i ORIG_HEAD, så att återställa den hårt till den återställer indexfilen och arbetsträdet till det tillståndet, och återställer grenens toppen till den incheckningen.

Även om det kan finnas lokala modifieringar i arbetsträdet, går det tryggt att köra "git pull" när det är känt att ändringen i den andra grenen inte överlappar dem.

Efter att ha granskat resultatet av sammanslagningen, kan du upptäcka att ändringen i den andra grenen är otillfredsställande. Om du kör git reset --hard ORIG_HEAD går du tillbaka till var du var, men det kommer att ignorera dina lokala ändringar, vilket du inte vill ha. git reset --merge behåller dina lokala ändringar.

Denna incheckning kommer att bli bortblåst så ett meddelande om bortkastad logg är okej.

Det tar bort WIP-incheckningen från incheckningshistoriken och ställer in arbetsträdet till tillståndet precis innan ögonblicksbilden skapades.

Vid det här laget innehåller indexfilen fortfarande alla WIP-ändringar som du har checkat in som en "ögonblicksbild WIP". Detta uppdaterar indexet så att dina WIP-filer visas som obehandlade.

Det tar bort filen från indexet medan den behålls i arbetskatalogen.

Detta checkar in alla andra ändringar i indexet.

Lägger till filen i indexet igen.

Det checkar in de första redigeringarna i branch1.

I den ideala världen hade det kunnat stå klart att den tidigare incheckningen inte hörde hemma i det nya ämnet när branch2 skapades och växlades till (d.v.s. git switch -c branch2 start), men ingen är perfekt.

Men du kan använda reset --keep för att ta bort den oönskade incheckningen efter att du har bytt till branch2.

Först, återställ historiken bakåt en incheckning så att vi tar bort den ursprungliga incheckningen, men lämnar arbetsträdet med alla ändringar. -N säkerställer att alla nya filer som läggs till med HEAD fortfarande är markerade så att git add -p hittar dem.

Därefter väljer vi interaktivt diff-stycken att lägga till med hjälp av funktionen git add -p. Detta kommer att fråga dig om varje diff-stycke i sekvens och du kan använda enkla kommandon som "ja, inkludera detta", "Nej, inkludera inte detta" eller till och med den mycket kraftfulla funktionen "redigera".

När du är nöjd med de ändringar du vill inkludera, bör du verifiera vad som har förberetts för den första incheckningen genom att använda git diff --cached. Detta visar alla ändringar som har flyttats till indexet och som snart kommer att checkas in.

Sedan checkas ändringarna som lagras i indexet in. Alternativet -c anger att incheckningsmeddelandet ska förfyllas med det ursprungliga meddelandet från den första incheckningen. Det är praktiskt för att slippa skriva om det. HEAD@{1} är en särskild notation för den incheckning som HEAD pekade på före den ursprungliga återställningsincheckningen (för 1 ändring sedan). Se git-reflog[1] för mer information. Det går också att använda vilken annan giltig incheckningsreferens som helst.

Du kan upprepa steg 2–4 flera gånger för att dela upp originalkoden i valfritt antal incheckningar.

Nu har du delat upp många av ändringarna i egna incheckningar, och kanske inte längre använder patch-läget för git add för att välja alla återstående oincheckade ändringar.

Kontrollera återigen att du har inkluderat det du vill. Du kan också kontrollera att git diff inte visar några återstående ändringar som ska checkas in senare.

Och slutligen skapa den slutliga incheckningen.