Informatie over Git-geschiedenis

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Git slaat de geschiedenis op als een grafiek van momentopnamen, ook wel doorvoeringen genoemd, van de hele opslagplaats. Elke doorvoering bevat ook een aanwijzer naar een of meer eerdere doorvoeringen. Doorvoeringen kunnen meerdere bovenouders hebben, waardoor een geschiedenis wordt gemaakt 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.

Notitie

Als u geen wijziging in uw Git-geschiedenis kunt vinden die u kent die u hebt aangebracht, kunt u meer informatie vinden over hoe vereenvoudiging van git-geschiedenis werkt bij Git mijn wijzigingen verloren: Een kijkje nemen bij de vereenvoudiging van de geschiedenis van Git.

Basisprincipes van doorvoergeschiedenis

Begin met een eenvoudig geschiedenisvoorbeeld: een opslagplaats met drie lineaire doorvoeringen.

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. De naam is omdat main dit de standaardnaam is voor de hoofdlijnvertakking in een Git-opslagplaats. Vertakkingen zijn verwijzen naar specifieke doorvoeringen. Daarom is vertakking zo licht en eenvoudig 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. Hiervoor haal ik de hoofdbranch op met de volgende opdracht:

git pull origin main

Hiermee worden alle doorvoeringen uit de main vertakking van de externe opslagplaats (standaard aangeroepen origin ) gekopieerd naar de vertakking van de main lokale opslagplaats. 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 vertakkingen te hebben waarbij u parallel aan verschillende functies 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 doorvoeringen, E en F.

Mijn doorvoeringen zijn bereikbaar door 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 doorvoering wanneer ik mijn vertakking in een andere vertakking heb samengevoegd. Dit is een samenvoegdoorvoering. 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 doorvoeringen uit hun eigen vertakkingen samenvoegen in de hoofdbranch rond dezelfde tijd.

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