7.7 Git-verktyg - Nollställning förklarad

Ett enklare sätt att tänka på reset och checkout är genom att se Git som en innehållsförvaltare av tre olika träd. Med "träd" menar vi egentligen "samling av filer", inte specifikt datastrukturen. Det finns några fall där indexet inte riktigt beter sig som ett träd, men för våra syften är det enklast att tänka så här just nu.

Git som system hanterar och manipulerar tre träd i sin normala drift:

Gits typiska arbetsflöde är att spela in ögonblicksbilder av ditt projekt i successivt bättre tillstånd, genom att manipulera dessa tre träd.

Låt oss visualisera processen: säg att du går in i en ny katalog med en enda fil. Vi kallar detta filens v1, och vi markerar den i blått. Nu kör vi git init, vilket skapar ett Git‑kodförråd med en HEAD-referens som pekar på den ännu ofödda master-grenen.

I det här läget har bara arbetskatalogträdet något innehåll.

Nu vill vi checka in den här filen, så vi använder git add för att ta innehållet i arbetskatalogen och kopiera det till indexet.

Sedan kör vi git commit, som tar innehållet i indexet och sparar det som en permanent ögonblicksbild, skapar ett incheckningsobjekt som pekar på den ögonblicksbilden och uppdaterar master till att peka på den incheckningen.

Om vi kör git status ser vi inga ändringar, eftersom alla tre träd är desamma.

Nu vill vi göra en ändring i den filen och checka in den. Vi går igenom samma process; först ändrar vi filen i vår arbetskatalog. Vi kallar detta filens v2, och markerar den i rött.

Om vi kör git status just nu ser vi filen i rött som "Ändringar som inte är köade för incheckning", eftersom den posten skiljer sig mellan indexet och arbetskatalogen. Nästa steg är att köa den med git add.

Vid det här laget, om vi kör git status, ser vi filen i grönt under "Ändringar att checka in" eftersom indexet och HEAD skiljer sig — det vill säga, vår föreslagna nästa incheckning skiljer sig nu från vår senaste incheckning. Till sist kör vi git commit för att färdigställa incheckningen.

Nu kommer git status inte att ge någon utdata, eftersom alla tre träd är identiska igen.

Att byta grenar eller klona går igenom en liknande process. När du växlar till en gren ändrar det HEAD till att peka på den nya grenreferensen, fyller ditt index med ögonblicksbilden av den incheckningen och kopierar sedan innehållet i indexet till din arbetskatalog.

Kommandot reset blir mer begripligt när man ser det i detta sammanhang.

För att exemplen ska bli tydligare, låt oss säga att vi har ändrat file.txt igen och checkat in den en tredje gång. Så nu ser historiken ut så här:

Låt oss nu gå igenom exakt vad reset gör när du anropar det. Det manipulerar direkt dessa tre träd på ett enkelt och förutsägbart sätt. Det gör upp till tre grundläggande operationer.

Det täcker beteendet hos reset i sin grundform, men du kan också ange en sökväg som kommandot ska påverka. Om du anger en sökväg kommer reset att hoppa över steg 1 och begränsa resten av sina åtgärder till en specifik fil eller uppsättning filer. Det är faktiskt ganska rimligt — HEAD är bara en pekare, och du kan inte peka på en del av en incheckning och en annan del av en annan. Men indexet och arbetskatalogen kan uppdateras delvis, så reset fortsätter med steg 2 och 3.

Så, anta att vi kör git reset file.txt. Den formen (eftersom du inte angav ett inchecknings-SHA‑1 eller en gren, och du inte angav --soft eller --hard) är en förkortning för git reset --mixed HEAD file.txt, vilket:

Så den kopierar i praktiken bara file.txt från HEAD till indexet.

Detta har den praktiska effekten att filen avköas. Om vi tittar på diagrammet för det kommandot och tänker på vad git add gör är de exakta motsatser.

Det är anledningen till att utdata från git status föreslår att du kör det här för att avköa en fil (se Ta bort en köad fil för mer om detta).

Vi skulle lika gärna kunna hindra Git från att anta att vi menade "dra data från HEAD" genom att ange en specifik incheckning att hämta den filversionen från. Vi skulle då köra något som git reset eb43bf file.txt.

Det gör i praktiken samma sak som om vi hade återställt innehållet i filen till v1 i arbetskatalogen, kört git add på den, och sedan återställt den tillbaka till v3 igen (utan att faktiskt gå igenom alla de stegen). Om vi kör git commit nu kommer det att registrera en ändring som återställer filen till v1, även om vi aldrig faktiskt hade den i arbetskatalogen igen.

Det är också intressant att notera att likt git add accepterar kommandot reset flaggan --patch för att avköa innehåll diffstycke för diffstycke. Så du kan selektivt avköa eller återställa innehåll.

Låt oss titta på hur du kan göra något intressant med den här nyfunna kraften — sammanfoga incheckningar.

Säg att du har en serie incheckningar med meddelanden som "oops.", "WIP" och "forgot this file". Du kan använda reset för att snabbt och enkelt sammanfoga dem till en enda incheckning som får dig att se riktigt smart ut. Sammanfoga incheckningar visar ett annat sätt att göra detta, men i det här exemplet är det enklare att använda reset.

Låt oss säga att du har ett projekt där den första incheckningen har en fil, den andra incheckningen lade till en ny fil och ändrade den första, och den tredje incheckningen ändrade den första filen igen. Den andra incheckningen var ett arbete på gång och du vill sammanfoga den.

Du kan köra git reset --soft HEAD~2 för att flytta HEAD-grenen tillbaka till en äldre incheckning (den senaste incheckningen du vill behålla):

Och sedan helt enkelt köra git commit igen:

Nu kan du se att din nåbara historik, den historik du skulle skicka, nu ser ut som att du hade en incheckning med file-a.txt v1, och sedan en andra som både ändrade file-a.txt till v3 och lade till file-b.txt. Incheckningen med v2-versionen av filen finns inte längre i historiken.

Till sist kanske du undrar vad skillnaden är mellan checkout och reset. Likt reset manipulerar checkout de tre träden, och det är lite olika beroende på om du ger kommandot en sökväg eller inte.

Förhoppningsvis förstår du nu och känner dig mer bekväm med kommandot reset, men du är sannolikt fortfarande lite förvirrad över hur exakt det skiljer sig från checkout och kan knappast minnas alla regler för de olika varianterna.

Här är en fusklapp för vilka kommandon som påverkar vilka träd. Kolumnen "HEAD" visar "REF" om det kommandot flyttar referensen (grenen) som HEAD pekar på, och "HEAD" om det flyttar HEAD självt. Var särskilt uppmärksam på kolumnen "AK säker?" — om den säger NEJ, stanna upp och fundera innan du kör kommandot.