Förstå Git-historik

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Git lagrar historiken som ett diagram över ögonblicksbilder – så kallade incheckningar – för hela lagringsplatsen. Varje commit innehåller också en pekare till en eller flera tidigare commit. Kommandon kan ha flera föräldrar, vilket skapar en historik som ser ut som en graf snarare än 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.

Grunderna i commithistorik

Börja med ett enkelt historikexempel: ett repo 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å commit C är en gren. Det namnges main eftersom det är standardnamnet för mainline-grenen i en Git-lagringsplats. Grenar är pekare till specifika commit, vilket gör att förgrening är så lättviktigt 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 kommer jag att hämta 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-operationen kopierade en ny commit, och grenen main på den lokala lagringsplatsen pekar nu på denna nya commit.

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 commit. Jag ska göra några ändringar på grenen cool-new-feature i två nya åtaganden, E och F.

Mina commits är tillgängliga i 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 commit när jag slår ihop min gren med en annan gren. Det här är en merge commit. Det finns inga ändringar i den här sammanfogningscommitten eftersom jag inte hade konflikter. Om jag hade konflikter skulle sammanslagningsåtgärden omfatta 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 slår samman commits från sina egna grenar till huvudgrenen vid ungefär samma tidpunkt.

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