Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Vereenvoudiging van Git-geschiedenis kan een verwarrend beest zijn. 99% van de tijd weet je niet eens dat het bestaat, maar af en toe duikt het op uit de donkere hoeken van Git en bijt het je. In dit artikel verkennen we wat vereenvoudiging van de geschiedenis is en hoe dit verwarring kan veroorzaken bij het bekijken van de bestandsgeschiedenis.
Laten we beginnen met een veelvoorkomend scenario:
- U drukt een wijziging naar een bestand en voegt de wijziging vervolgens samen in de hoofdbranch.
- Sommige collega's voegen hun takken ook samen in de hoofdbranch.
- U komt later terug en u ziet dat uw wijzigingen ontbreken.
- Op zoek naar de schuldige, ga je kijken naar de bestandsgeschiedenis en let op... worden uw wijzigingen niet eens vermeld!?
Git-commitgeschiedenis is een boom. Soms is de chronologische geschiedenis niet hetzelfde als de werkelijke bestandsstructuurgeschiedenis. Deze situatie treedt meestal op wanneer een doorvoerbewerking een bestand terug zet naar de oorspronkelijke staat. In dat geval worden in de standaardgeschiedenisweergave niet alle wijzigingenweergegeven, omdat het bestand technisch gezien niet is gewijzigd. In dit scenario realiseert Git zich dat het de geschiedenis kan vereenvoudigen en dat de 'wijzigingen' die u waarschijnlijk zoekt, uit het logboek worden verwijderd.
Tenzij je het eerder bent tegengekomen, word je misschien gefrustreerd en vraag je je af Waar zijn mijn wijzigingen in hemelsnaam gebleven?
Geschiedenisvereenvoudiging: Standaard actief
Standaard vereenvoudigt het uitvoeren van de log-opdracht op een bestand: git log file.txt
automatisch de geschiedenis, waarbij mogelijk sommige doorvoeringen uit de uitvoer worden verborgen. Zie git log man-paginavoor meer informatie.
Wat aan de verwarring toevoegt, is dat de vereenvoudiging van de geschiedenis niet optreedt als u git log
uitvoert, omdat u alle wijzigingen bekijkt die u niet hoeft te vereenvoudigen.
Als u de vereenvoudiging van de geschiedenis wilt uitschakelen, moet u de opdrachtregelschakelaar --full-history
gebruiken.
Een voorbeeld van de vereenvoudiging van de geschiedenis
Om beter te begrijpen hoe vereenvoudiging werkt, maken we ons eigen voorbeeld van de vereenvoudiging van de geschiedenis. Laten we eerst eens kijken naar een diagram van de geschiedenis die we gaan maken:
Zoals u kunt zien, gaan we het volgende doen:
- Maak een bestand.
- Voeg een regel toe aan dat bestand in een branch (dieren).
- Voeg een andere regel toe aan dat bestand in een andere tak (fruit).
- Voeg branch dieren samen terug in main.
- Voeg de branch fruit terug in de main branch en kies de volledige versie van het bestand van de fruit branch.
- Controleer de geschiedenis van het bestand.
Git vereenvoudigt de geschiedenis voor ons. Stap 5 is hier cruciaal. We negeerden alle wijzigingen van de dierlijke tak. Git merkt op dat ons bestand in wezen geen wijzigingen heeft ondergaan tussen stap 1 en stap 5, en het zal ons daarom alleen twee geschiedenisvermeldingentonen.
Eerst maken we het bestand en voegen we het toe aan onze opslagplaats:
> cd sample
> git init
> echo "some content" > test.txt
> git add test.txt
> git commit -m "Initial commit"
Nu besluiten we de tekst 'ezels' toe te voegen aan het bestand in een dierenvertakking:
> git checkout -b animals
> echo "donkeys" >> test.txt
> git commit -am "We have added an animal"
Terwijl we experimenteren, besluiten we misschien dat we in plaats daarvan met fruit in ons bestand willen gaan, dus maken we een andere vertakking en voegen we de tekst 'bananen' toe aan het einde van het bestand:
> git checkout main -b fruit
> echo "bananas" >> test.txt
> git commit -am "We have added a fruit"
Tevreden met onze wijzigingen, besluiten we om onze dierentak weer terug samen te voegen in de hoofdbranch.
> git checkout main
> git merge animals
Laten we nu het logboek bekijken voor ons test.txt
-bestand:
> git log test.txt
commit 6b33d99b996c430a60c9552b79245d1aa8320339
Date: Mon Feb 15 10:45:33 2016 -0500
We have added an animal
commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
Date: Mon Feb 15 10:44:18 2016 -0500
Initial commit
Tot nu toe zo goed, toch? Niets ziet er gewoon uit in onze logboekuitvoer. Laten we nu zeggen dat we van gedachten veranderden en besloten om onze fruittak samen te voegen:
>git merge fruit
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.
Uh-oh, een samenvoegingsconflict. Na enige overweging besluiten we om het hele test.txt
bestand uit onze fruittak te te gebruiken. Normaal gesproken gebruikt u een teksteditor of hulpprogramma voor samenvoegen, maar we maken gewoon het hele bestand opnieuw, omdat dit slechts twee regels is:
> echo "some content" > test.txt
> echo "bananas" >> test.txt
> git commit -am "Fixed merge conflict"
Laten we nu eens kijken naar de geschiedenis van ons test.txt
bestand:
> git log test.txt
commit fdd4dfd816c4efebc5bdb240f49e934e299db581
Date: Mon Feb 15 10:51:06 2016 -0500
We have added a fruit
commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
Date: Mon Feb 15 10:44:18 2016 -0500
Initial commit
Inderdaad, we zien geen wijzigingen van ons eerste experiment in het logboek, en we zien onze samenvoeging ook niet. Zijn ze er nog? Zijn de wijzigingen volledig door Git verwijderd?
> git log --full-history test.txt
Zoals u kunt zien, hoewel het logboek zonder de vlag full-history
is vereenvoudigd, heeft Git al onze wijzigingen bewaard:
> commit 5d0bb77a24e265dc154654fb3b5be331b53bf977
Merge: 6b33d99 fdd4dfd
Date: Mon Feb 15 10:59:34 2016 -0500
Fixed merge conflict
commit fdd4dfd816c4efebc5bdb240f49e934e299db581
Date: Mon Feb 15 10:51:06 2016 -0500
We have added a fruit
commit 6b33d99b996c430a60c9552b79245d1aa8320339
Date: Mon Feb 15 10:45:33 2016 -0500
We have added an animal
commit 206613ccd9a54b055b184c7b6c16f2ece8067e51
Date: Mon Feb 15 10:44:18 2016 -0500
Initial commit
Samenvatting van vereenvoudiging van Git-geschiedenis
Het belangrijkste van de vereenvoudiging van de geschiedenis is dat u het meestal nooit zult merken. Maar wanneer een samenvoegingsconflict fout gaat en u wilt weten wat er is gebeurd, kunt u de git-logboekgeschiedenis bekijken en zich afvragen waar uw wijzigingen zijn gegaan.
In plaats van in paniek te raken, weet je dat:
- Geschiedenis vereenvoudigen voor bestanden is standaard ingeschakeld
- Met de vlag
--full-history
krijgt u een uitgebreidere bestandsgeschiedenis
Update: Sinds ik dit artikel heb geschreven, heeft Azure DevOps Services een aantal geweldige weergaveopties voor geschiedenis geïntroduceerd op het web. Wat dit betekent, is dat als u niet door de opdrachtregel wilt lopen, u gewoon het bestand kunt ophalen waarvoor u de geschiedenis wilt bekijken in onze verkenner. U krijgt het onderstaande geschiedenisfilter te zien, waar u eenvoudige of niet-eenvoudige geschiedenisweergaven kunt opgeven:
c) 2016 Microsoft Corporation. Alle rechten voorbehouden. Dit document wordt verstrekt "as-is." Informatie en meningen die in dit document worden uitgedrukt, inclusief URL's en andere internetverwijzingen, kunnen zonder voorafgaande berichtgeving worden gewijzigd. U gebruikt deze op eigen risico.
Dit document biedt u geen wettelijke rechten voor enig intellectueel eigendom in een Microsoft-product. U mag dit document kopiëren en gebruiken voor uw eigen referentiedoeleinden.