Informatie over Git-geschiedenis

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

Git slaat de geschiedenis op als een grafische structuur van momentopnamen — ook wel commits genoemd — van de hele opslagplaats. Elke doorvoering bevat ook een aanwijzer naar een of meer eerdere doorvoeringen. Commits kunnen meerdere parent-commits hebben, waardoor een geschiedenis wordt gecreëerd die eruitziet als een grafiek in plaats van een rechte lijn. Dit verschil in geschiedenis is ongelooflijk belangrijk en is de belangrijkste reden dat gebruikers Git verwarrend vinden.

Basisbeginselen van de commitgeschiedenis

Beginnen met een eenvoudig geschiedenisvoorbeeld: een opslagplaats met drie lineaire commits.

Doorvoer A is het bovenliggende item van doorvoer B en doorvoer B is het bovenliggende item van doorvoer C. Deze geschiedenis lijkt erg op een CVCS. De pijl die wijst naar doorvoer C is een vertakking. Het heet main omdat dat de standaardnaam is voor de hoofdtak in een Git-repository. Vertakkingen wijzen naar specifieke commits. Daarom is vertakken zo lichtgewicht en gemakkelijk in Git.

Een belangrijk verschil in Git in vergelijking met CVCS is dat ik mijn eigen volledige kopie van de opslagplaats heb. Ik moet mijn lokale opslagplaats gesynchroniseerd houden met de externe opslagplaats door de meest recente doorvoeringen uit de externe opslagplaats op te halen. Om dit te doen, haal ik de hoofdbranch op met de volgende opdracht:

git pull origin main

Hiermee worden alle commits van de main-vertakking van de externe opslagplaats (standaard genoemd origin) naar de main-vertakking van de lokale opslagplaats gekopieerd. De pull-bewerking heeft één nieuwe doorvoer gekopieerd en de main vertakking in de lokale opslagplaats verwijst nu naar deze nieuwe doorvoer.

Vertakkingsgeschiedenis begrijpen

Nu wil ik mijn code wijzigen. Het is gebruikelijk om meerdere actieve takken te hebben waarbij u parallel aan verschillende functionaliteiten werkt. Dit is in star contrast met CVCS waar nieuwe vertakkingen zwaar zijn en zelden worden gemaakt. De eerste stap bestaat uit het uitchecken naar een nieuwe vertakking met behulp van de volgende opdracht:

git checkout -b cool-new-feature

Dit is een snelkoppeling die twee opdrachten combineert: git branch cool-new-feature om de vertakking te maken, gevolgd door git checkout cool-new-feature te beginnen met werken in de vertakking.

Twee vertakkingen verwijzen nu naar dezelfde doorvoering. Ik breng een paar wijzigingen aan in de cool-new-feature vertakking in twee nieuwe commits, E en F.

Mijn commits zijn bereikbaar via de cool-new-feature vertakking omdat ik ze in die vertakking heb gemaakt. Ik ben klaar met mijn functie en wil deze samenvoegen in main. Hiervoor gebruik ik de volgende opdracht:

git merge cool-feature main

De grafiekstructuur van de geschiedenis wordt zichtbaar wanneer er een samenvoeging is. Git maakt een nieuwe commit aan wanneer ik mijn vertakking in een andere vertakking samenvoeg. Dit is een samengevoegde commit. Er zijn geen wijzigingen opgenomen in deze samenvoegingsdoorvoering, omdat ik geen conflicten had. Als ik conflicten had, bevat de samenvoeging de wijzigingen die nodig zijn om deze conflicten op te lossen.

Geschiedenis in de echte wereld

Hier volgt een voorbeeld van de Git-geschiedenis die meer lijkt op code in actieve ontwikkeling in een team. Er zijn drie personen die commits uit hun eigen vertakkingen samenvoegen in de hoofdvertakking rond dezelfde tijd.

Nu u begrijpt hoe vertakkingen en samenvoegingen de vorm van de grafiek maken, zou dit niet te eng moeten zijn.