Git prune

De output van git-log toont de twee commits en de bijbehorende commitberichten over de wijzigingen die zijn aangebracht in hello.txt. De volgende stap is dat we een van de commits onbereikbaar maken. We doen dit met de opdracht git reset. We hebben de status van de repo teruggezet naar de eerste commit, de commit 'added hello.txt'.

Als we nu git log gebruiken om de status van de repository te onderzoeken, zien we dat we maar één commit hebben.

De demo-repository bevindt zich nu in een staat die een losgekoppelde commit bevat. De tweede commit die we hebben gemaakt met het bericht 'added another line to hello.txt', wordt niet langer weergegeven in de output van git log en is nu losgekoppeld. Het lijkt misschien alsof we de commit verloren of verwijderd hebben, maar Git is erg strikt als het gaat om het niet verwijderen van geschiedenis. We kunnen bevestigen dat de commit nog steeds beschikbaar is (maar is losgekoppeld) door git checkout te gebruiken om de commit rechtstreeks te bezoeken:

Als we de losgekoppelde commit bekijken, is Git erop bedacht om ons gedetailleerd uit te leggen dat we ons in een losgekoppelde toestand bevinden. Als we de log hier bekijken, zien we dat de commit 'added another line to hello.txt' weer terug is in de outputlog! Nu we weten dat de repository zich in een goede simulatietoestand bevindt met een losgekoppelde commit, kunnen we oefenen met git prune. Maar laten we eerst teruggaan naar de main-branch via git checkout

Als je via git checkout terugkeert naar main, laat Git weten dat we een losgekoppelde commit achterlaten. Het is nu tijd om de losgekoppelde commit op te schonen! Vervolgens voeren we git clean uit, maar we moeten daar enkele opties aan doorgeven. --dry-run en --verbose leveren output op die aangeeft wat er opgeschoond gaat worden zonder het daadwerkelijk op te schonen.

Deze opdracht zal waarschijnlijk lege output retourneren. Lege output houdt in dat er met opschonen eigenlijk niets wordt verwijderd. Hoe kan dit gebeuren? Wel, de commit is waarschijnlijk niet volledig losgekoppeld. Ergens bevat Git er nog steeds een verwijzing naar. Dit is een goed voorbeeld van waarom git prune niet op zichzelf gebruikt mag worden buiten git gc. Dit is ook een goed voorbeeld dat laat zien hoe moeilijk het is om gegevens volledig te verliezen met Git.

Hoogstwaarschijnlijk slaat Git een referentie op naar onze losgekoppelde commit in de reflog. We kunnen dit onderzoeken door git reflog uit te voeren. Je zou wat output moeten zien waarin de volgorde wordt beschreven van de acties die we hebben ondernomen om dit te bereiken. Ga voor meer informatie over git reflog naar de pagina git reflog. Git bewaart niet alleen de geschiedenis in de reflog, maar heeft ook interne vervaldatums voor het verwijderen van losgekoppelde commits. Nogmaals, dit zijn allemaal implementatiedetails die git gc verwerkt en git prune mag niet op zichzelf worden gebruikt.

Om onze demo van de git prune-simulatie af te sluiten, moeten we de reflog wissen.

Met de bovenstaande opdracht vervalt alle invoer voor de reflog die ouder is dan nu. Dit is een en grove en gevaarlijke opdracht die je nooit zou moeten gebruiken als informeel Git-gebruiker. We voeren deze opdracht uit om een succesvolle git prune te illusteren. Nu de reflog volledig is gewist, kunnen we nu git prune uitvoeren.

Deze opdracht moet een lijst met Git SHA-objectreferenties opleveren die er als hierboven uitziet.

git prune biedt een korte lijst met opties die we hebben besproken in het overzichtsgedeelte.

Voer het opschonen niet uit. Laat alleen een output zien van wat er gaat gebeuren

Geef de output weer van alle objecten en acties waarop het opschonen betrekking heeft

Geeft de output weer die de voortgang van het opschonen aangeeft

Verval forceren van objecten die afgelopen zijn

Als je een ＜head＞ specificeert, blijven alle opties van die head-ref behouden

git remote prune en git fetch --prune doen hetzelfde: de refs verwijderen naar branches die niet op de remote bestaan. Dit is zeer wenselijk als je in een teamworkflow werkt waarin externe branches worden verwijderd na samenvoeging met main. De tweede opdracht, git fetch --prune, maakt verbinding met de remote en haalt de laatste externe status op voordat je gaat opschonen. Het is in wezen een combinatie van opdrachten:

De generieke opdracht git prune is volledig anders. Zoals besproken in het overzichtsgedeelte, verwijdert git prune lokaal losgekoppelde commits.

git fetch --prune is de beste tool voor het opschonen van verouderde branches. De tool maakt verbinding met een gedeelde externe repository en haalt alle refs naar externe branches op. Vervolgens worden de externe refs verwijderd die niet langer in gebruik zijn in de externe repository.

Nee. git remote prune origin verwijdert alleen refs naar externe branches die niet meer bestaan. Git slaat zowel lokale als externe refs op. Een repository bevat local/origin- en remote/origin-refcollecties. git remote prune origin schoont alleen de refs in remote/origin op. Zo blijft lokaal werk in local/origin veilig.

De opdracht git prune is bedoeld om aangeroepen te worden als onderliggende opdracht voor git gc. Het is zeer onwaarschijnlijk dat je git prune ooit zult moeten aanroepen in het kader van dagelijkse software-engineering. Er zijn andere opdrachten nodig om de effecten van git prune te begrijpen. Enkele opdrachten die in dit artikel zijn gebruikt, zijn git log, git reflog en git checkout.