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 ber dig att hämta (pull), och ändringarna låter värda att sammanslås.

Du har dock redan smutsat ner indexet (dvs. ditt index matchar inte HEAD-incheckningen). Men du vet att den pull du ska göra inte påverkar frotz.c eller filfre.c, så du återställer indexändringarna för dessa två filer. Dina ändringar i arbetskatalog finns kvar där.

Sedan kan du hämta och sammanfoga, och lämna ändringarna av frotz.c och filfre.c kvar i arbetskatalogen.

Detta görs oftast när du kommer ihåg att det du just checkade-in är ofullständigt, eller att du stavade ditt inchecknings-meddelande fel, eller båda. Lämnar arbetskatalogen som det var före "återställning".

Gör korrigeringar till arbetskatalogs-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 istä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 sammanslagnings-incheckning, så git reset --hard som är en synonym för git reset --hard HEAD rensar bort röran från indexfilen och arbetskatalogen.

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

Men du har bestämt dig för att ämnesgrenen 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 din indexfil och arbetskatalogen till det tillståndet, och återställer grenens toppen till den incheckningen.

Även om du kan ha lokala modifieringar i ditt arbetskatalog, kan du tryggt säga "git pull" när du vet 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.

Detta tar bort WIP-incheckningen från inchecknings-historiken och ställer in ditt arbetskatalog till tillståndet precis innan du skapade den ögonblicksbilden.

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.

Detta 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.

Detta checkar-in dina första redigeringar i branch1.

I den ideala världen hade du kunnat inse att den tidigare incheckningen inte hörde hemma i det nya ämnet när du skapade och bytte till branch2 (dvs. 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 arbetskatalogen 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, checka-in ändringarna som lagras i indexet. Alternativet -c anger att inchecknings-meddelandet ska förfyllas från det ursprungliga meddelandet som du började med i den första incheckningen. Detta är praktiskt för att undvika att skriva om det. HEAD@{1} är en speciell notation för den incheckning som HEAD brukade vara vid före den ursprungliga återställnings-incheckningen (för 1 ändring sedan). Se git-reflog[1] för mer information. Du kan också använda vilken annan giltig inchecknings-referens 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.