Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Git representerar historik på ett helt annat sätt än cvcs (centraliserade versionskontrollsystem) som Team Foundation Version Control, Perforce eller Subversion. Centraliserade system lagrar en separat historik för varje fil på en lagringsplats. Git lagrar historik som ett diagram över ögonblicksbilder av hela lagringsplatsen. Dessa ögonblicksbilder, som kallas commits i Git, kan ha flera föräldrar, 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ändare som är bekanta med CVCS tycker att Git är förvirrande.
Grunderna i commithistorik
Börja med ett enkelt historikexempel: en lagringsplats med tre 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. 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 utvecklaren har en egen fullständig kopia av lagringsplatsen. De måste hålla sin lokala lagringsplats synkroniserad med fjärrlagringsplatsen genom att hämta de senaste incheckningarna från fjärrlagringsplatsen. För att göra detta, drar de in huvudgrenen med följande kommando:
git pull origin main
Detta sammanfogar alla ändringar från huvudgrenen på fjärrlagringsplatsen, som Git namnger origin som standard. Den här hämtningen medförde en ny commit och huvudgrenen i den lokala lagringsplatsen flyttas till denna.
Förstå grenhistorik
Nu är det dags att ändra koden. Det är vanligt att ha flera aktiva grenar nä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-featureför att skapa grenen -
git checkout cool-new-featureför att börja arbeta i branchen
Två grenar pekar nu på samma commit. Anta att det finns några ändringar på grenen cool-new-feature i två nya commits, E och F.
Ändringarna är nåbara från grenen cool-new-feature eftersom de har committats till den grenen.
Nu när funktionen är klar måste den sammanfogas till huvudgrenen. Använd följande kommando för att göra det:
git merge cool-new-feature main
Grafstrukturen i historiken blir synlig när det finns en sammanslagning. Git skapar en ny kommitt när grenen sammanfogas med en annan gren. Det här är en merge commit. Det ingår inga ändringar i den här sammanfogningskommitt, eftersom det inte fanns några konflikter. Om det fanns konflikter skulle sammanfogningskommitten innehålla de ändringar som behövs för att lösa dem.
Historia i den verkliga världen
Här är ett exempel på Git-historik som liknar kod i aktiv utveckling i ett team.
Det finns tre personer som slår samman commit från sina egna grenar till main-grenen ungefär samtidigt.
Nästa steg
Läs mer om att arbeta med Git-historik i GitHub och Azure Repos eller förenkling av Git-logghistorik.