Förstå Git-historik

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Git lagrar historiken som ett diagram över ögonblicksbilder – så kallade incheckningar – för hela lagringsplatsen. Varje incheckning innehåller också en pekare till en eller flera tidigare incheckningar. Incheckningar kan ha flera överordnade, vilket skapar en historik som ser ut som ett diagram i stället för en rak linje. Den här skillnaden i historia är otroligt viktig och är den främsta anledningen till att användarna tycker att Git är förvirrande.

Kommentar

Om du inte hittar en ändring i din Git-historik som du vet att du har gjort kan du lära dig mer om hur Git-historikförenkling fungerar på Git förlorade mina ändringar: Ta en titt på Gits historikförenkling.

Grunderna i incheckningshistorik

Börja med ett enkelt historikexempel: en lagringsplats med 3 linjära incheckningar.

Incheckning A är överordnad för incheckning B och incheckning B är överordnad till incheckning C. Den här historiken ser mycket lik en CVCS. Pilen som pekar på incheckningen C är en gren. Det namnges main eftersom det är standardnamnet för mainline-grenen i en Git-lagringsplats. Grenar är pekare för specifika incheckningar, varför förgrening är så enkelt och enkelt i Git.

En viktig skillnad i Git jämfört med CVCS är att jag har min egen fullständiga kopia av lagringsplatsen. Jag måste hålla min lokala lagringsplats synkroniserad med fjärrlagringsplatsen genom att hämta de senaste incheckningarna från fjärrlagringsplatsen. För att göra detta hämtar jag huvudgrenen med följande kommando:

git pull origin main

Detta kopierar ("hämtar") alla incheckningar från grenen main av fjärrlagringsplatsen (anropas origin som standard) till grenen main av den lokala lagringsplatsen. Pull-åtgärden kopierade en ny incheckning och grenen main på den lokala lagringsplatsen pekar nu på den nya incheckningen.

Förstå grenhistorik

Nu vill jag göra en ändring i min kod. Det är vanligt att ha flera aktiva grenar där du arbetar med olika funktioner parallellt. Detta står i skarp kontrast till CVCS där nya grenar är tunga och sällan skapade. Det första steget är att checka ut till en ny gren med hjälp av följande kommando:

git checkout -b cool-new-feature

Det här är en genväg som kombinerar två kommandon: git branch cool-new-feature för att skapa grenen följt av git checkout cool-new-feature för att börja arbeta i grenen.

Två grenar pekar nu på samma incheckning. Jag ska göra några ändringar på grenen cool-new-feature i två nya incheckningar, E och F.

Mina incheckningar kan nås av grenen cool-new-feature eftersom jag gjorde dem i den grenen. Jag är klar med min funktion och vill sammanfoga den till main. För att göra det använder jag följande kommando:

git merge cool-feature main

Grafstrukturen i historiken blir synlig när det finns en sammanslagning. Git skapar en ny incheckning när jag sammanfogade min gren till en annan gren. Det här är en sammanslagningscheckning. Det finns inga ändringar som ingår i den här sammanslagningsincheckning eftersom jag inte hade konflikter. Om jag hade konflikter skulle sammanslagningsincheckningen innehålla de ändringar som krävs för att lösa dessa konflikter.

Historia i den verkliga världen

Här är ett exempel på Git-historik som mer liknar kod i aktiv utveckling i ett team. Det finns tre personer som sammanfogar incheckningar från sina egna grenar till huvudgrenen ungefär samtidigt.

Nu när du förstår hur grenar och sammanslagningar skapar grafens form bör det inte vara för skrämmande!