Git Reflog: Begrijpen en Gebruiken van Referentielogs in Git

Er is niets vervelender voor een ontwikkelaar of data-engineer dan per ongeluk git-branches te verwijderen of commits te resetten wanneer je dat niet wilde. Daarom ben ik blij iets te delen dat ik uit mijn eigen ervaring heb geleerd en dat ik had willen leren eerder, namelijk hoe je git reflog gebruikt. git reflog is een van die technieken die absoluut de moeite waard is om te leren; als je nu een beetje tijd investeert, kun je in de toekomst een grote hoofdpijn besparen.

Hoewel ik je git reflog zal laten zien, wat ik echt nuttig vind om te navigeren en te herstellen van fouten, wil ik ook onze Fundamentals of Git en Introductie tot GitHub Concepten cursussen aanbevelen om alles te leren wat er te weten valt over versiebeheer.

Wat is git reflog?

Git reflog, of referentielog, is een lokaal volgmechanisme dat updates aan takpunten en de HEAD-referentie in een Git-repository registreert. (In de context van Git verwijst HEAD naar de huidige commit waarop je werkdirectory en staginggebied zijn gebaseerd.)

In tegenstelling tot git log, dat de commitgeschiedenis op basis van afstamming weergeeft en laat zien hoe commits in een branch zijn verbonden, legt git reflog alle bewegingen van HEAD vast, inclusief takwisselingen, rebases, resets en commits. Dit maakt reflog nuttig voor het herstellen van verloren commits en het oplossen van recente acties.

Wanneer worden reflog-invoer aangemaakt?

Reflogvermeldingen worden aangemaakt telkens wanneer u handelingen uitvoert die de status van HEAD of branch-referenties wijzigen. Veelvoorkomende scenario’s zijn onder andere:

• Wijzigingen committen met git commit.

• Een andere branch checken met git checkout branch_naam.

• Een nieuwe branch creëren met git branch nieuwe_branch.

• Rebasen met git rebase

• Terugzetten naar een vorige commit met git reset --hard.

• Branches samenvoegen met git merge.

Hier is de code die je gebruikt om updates in het lokale repository bij te houden:

git reflog

Het gebruik van git reflog om updates in het lokale repository bij te houden. Afbeelding door Auteur.

Hoe interpreteer je de uitvoer van git reflog?

Je kunt de uitvoer als volgt interpreteren:

• HEAD@{0}: De meest recente actie was het overschakelen naar de HEAD-tak.

• HEAD@{1}: Daarvoor had ik het bestandstype van .xlxs naar .csv formaat gewijzigd.

• HEAD@{2}: Ik maakte de eerste commit toen ik de bestanden naar het repository pushte.

Elke invoer toont:

• De commit-hash (fa82776)

• De reflog-index (HEAD@{0}, HEAD@{1}, enz.)

• Een beschrijving van de actie die is uitgevoerd (commit, checkout, rebase)

Hoe git reflog te gebruiken

Git reflog biedt een manier om referentie-updates bij te houden en eerdere staten van je repository te herstellen. Door te begrijpen hoe je door reflog-items kunt navigeren, kun je verloren commits herstellen, wijzigingen ongedaan maken en eerdere versies van je werk vergelijken.

Basale git reflog-opdracht

Hieronder staat de basale reflog-opdracht:

git reflog

De bovenstaande opdracht geeft een lijst weer van recente acties die HEAD of branch-referenties hebben bijgewerkt, inclusief commits, branch-switches, resets, rebases en meer. Elk item is geïndexeerd, zoals HEAD@{0} en HEAD@{1}, om zijn positie in de reflog-geschiedenis aan te geven.

Verwijzen naar eerdere staten

Git reflog dient als een record van eerdere referentie-updates, waardoor we eerdere punten in de geschiedenis van onze repository kunnen lokaliseren en herstellen. Zonder het zouden deze referenties niet bestaan, en zouden we exacte commit-hashes nodig hebben om naar specifieke eerdere toestanden terug te keren. Laten we nu verkennen hoe Git ons in staat stelt om deze eerdere toestanden te navigeren met git checkout.

HEAD@{n}: Verwijst naar een specifieke reflog-invoer, waarbij n de index is. Bijvoorbeeld, HEAD@{2} verwijst naar de derde meest recente staat van HEAD.

git checkout HEAD@{2}

Gebruik git checkout om eerdere wijzigingen bij te houden. Afbeelding door Auteur.

branch@{time}: Verwijst naar de staat van een tak op een specifiek tijdstip. Bijvoorbeeld, main@{1.week.ago} verwijst naar de staat van de hoofdtak een week geleden terwijl feature@{yesterday} verwijst naar de staat van de functietak gisteren.

git checkout main@{1.week.ago}

Het gebruik van git checkout om veranderingen uit het verleden bij te houden. Afbeelding door Auteur.

Tijdgebaseerde kwalificaties

git reflog helpt ons niet alleen bij het herstellen van eerdere staten, maar stelt ons ook in staat om ze te vergelijken. Aangezien reflog referentie-updates bijhoudt, kunnen we het gebruiken om te zien hoe onze repository in de loop van de tijd is veranderd. Laten we nu bekijken hoe git diff gebruik maakt van reflog-items om vroegere en huidige staten te vergelijken.

De volgende zijn voorbeelden van tijdkwalificaties die het gemakkelijk maken om uw repository te herstellen naar een specifiek tijdstip in plaats van alleen te vertrouwen op reflog-indexnummers.

git checkout HEAD@{1.minute.ago}     # Staat van één minuut geleden

git checkout HEAD@{1.hour.ago}       # Staat van één uur geleden

git checkout HEAD@{1.week.ago}       # Staat van één week geleden

git checkout HEAD@{yesterday}        # Status van gisteren

git checkout HEAD@{2024-01-01.12:00:00} # Status op een specifiek tijdstip

Vergelijk eerdere statussen met git diff

Je kunt eerdere statussen vergelijken met commando’s zoals git diff. Het volgende commando vergelijkt de huidige status van de hoofdbranch main@{0} met zijn status van één dag geleden, main@{1.day.ago}. De output zal eventuele verschillen tussen deze twee snapshots tonen.

git diff main@{0} main@{1.day.ago}

Vergelijk eerdere statussen met git diff. Afbeelding door Auteur.

Veelvoorkomende Gebruiksscenario’s voor Git Reflog

Git reflog is een onschatbare tool voor het herstellen van verloren wijzigingen, het ongedaan maken van fouten en het oplossen van veelvoorkomende Git-missers. Hieronder staan enkele praktijksituaties waarin git reflog van pas kan komen.

Herstellen van een verkeerde reset

Als je per ongeluk je branch hebt gereset met git reset --hard, kun je reflog gebruiken om je vorige status te herstellen.

git reset --hard HEAD@{3}

Herstellen van verloren commits

Als je per ongeluk een branch verwijdert of commits verliest door een reset of rebase, kun je de verloren commit vinden met behulp van git reflog.

git reflog

Zoek de commit-hash op in de reflog-uitvoer en check deze uit:

git checkout <commit-hash>

Zodra je de verloren commit hebt geverifieerd, kun je een nieuwe branch aanmaken om deze te behouden:

git branch recovered-branch <commit-hash>

Het repareren van een mislukte rebase

Als een rebase misgaat, kun je git reflog gebruiken om de pre-rebase commit te vinden en je branch te resetten. Identificeer de commit vóór de rebase en reset deze.

git reset --hard HEAD@{3}  # Pas het nummer aan op basis van de reflog-uitvoer

Een verwijderde branch herstellen

Als je per ongeluk een branch verwijdert, kun je deze herstellen met behulp van git reflog. Vind de laatst bekende commit van de verwijderde branch en maak deze opnieuw aan:

git branch restored-branch <commit-hash>

Stash-geschiedenis volgen

Git reflog kan ook worden gebruikt om de stash-geschiedenis te bekijken. Het onderstaande commando geeft stash-operaties weer, zodat je oudere stashes indien nodig kunt herstellen.

git reflog stash

Om een eerdere stash-entry toe te passen, gebruik je het volgende commando:

git stash apply stash@{2}

Bekijk onze Git Pull Force: Hoe een Lokale Branch Overschrijven met Remote handleiding om de beste werkwijzen voor het overschrijven van lokale wijzigingen te leren.

Git Reflog Subcommando’s en Opties

Git biedt verschillende subcommando’s en opties voor het beheren en interactie met reflogs.

Git reflog subcommando’s

Hieronder vind je een gestructureerd overzicht van belangrijke git reflog subcommando’s en hun gebruik.

git reflog show: Toont standaard de reflog-items voor HEAD of voor een gespecificeerde referentie zoals een branch.

git reflog show

Het gebruik van git reflog show om vermeldingen voor een specifieke referentie weer te geven. Afbeelding door auteur.

git reflog list: Deze opdracht toont alle referenties met een reflog. Het is handig om takken en HEAD-referenties te identificeren met opgeslagen reflogvermeldingen.

git reflog list

git reflog delete <ref>@{<specifier>}: Ruimt oude reflogvermeldingen op die de opgegeven tijdslimiet overschrijden. Bijvoorbeeld, de volgende opdracht verwijdert vermeldingen ouder dan 30 dagen.

git reflog expire --expire=30.days.ago

git reflog delete <ref>@{<specifier>}: Verwijdert een specifieke reflogvermelding op basis van zijn referentie en positie. De onderstaande opdracht verwijdert de reflogvermelding op index 2 voor HEAD.

git reflog delete HEAD@{2}

git reflog bestaat <ref>: Verifieert of er een reflog bestaat voor een specifieke referentie. Bijvoorbeeld, het onderstaande commando geeft succes terug als de hoofdbranch een reflog heeft.

git reflog exists main

Opties voor git-reflog-subcommando’s

De volgende zijn de opties die beschikbaar zijn voor de subcommando’s van git reflog en hun gebruik.

--expire-unreachable=<tijd>: Verwijdert alleen die reflogvermeldingen die onbereikbaar zijn vanaf een ref. Bijvoorbeeld, het onderstaande commando verwijdert reflogvermeldingen die ouder zijn dan 7 dagen en onbereikbaar zijn.

git reflog expire --expire-unreachable=7.days.ago

--all: Verwerkt reflogs voor alle referenties, niet alleen voor HEAD. Het onderstaande commando ruimt alle reflogs ouder dan 60 dagen op voor alle branches.

git reflog expire --expire=60.days.ago --all

--droge-run: Simuleert de uitvoering van een opdracht en toont wat er zou worden verwijderd zonder daadwerkelijk iets te verwijderen. Bijvoorbeeld, de onderstaande opdracht toont welke items zouden worden verwijderd.

git reflog expire --expire=30.days.ago --dry-run

--uitgebreid: Biedt gedetailleerde output over de acties uitgevoerd door de opdracht. De onderstaande opdracht toont uitgebreide details bij het verlopen van oude reflog-items.

git reflog expire --expire=90.days.ago --verbose

Git Reflog vs. Git Log: Belangrijkste Verschillen

Zowel git log als git reflog bieden inzicht in de geschiedenis van een repository, maar ze hebben verschillende doeleinden. Laten we naar deze verschillen kijken om te begrijpen hoe elk kan worden gebruikt voor versiebeheer en herstelstrategieën.

• git log toont de commitgeschiedenis door de afstamming van commits in een branch te volgen. Het biedt een chronologisch overzicht van hoe de inhoud van de repository zich heeft ontwikkeld.

• git reflog registreert updates aan referenties zoals HEAD, branches en stashes, inclusief acties zoals branch switches, resets, rebases en meer. Het houdt wijzigingen bij die mogelijk geen deel uitmaken van de commitstamboom.

• git reflog is strikt lokaal op jouw machine en wordt niet gedeeld met externe repositories.

• Hoewel git log geen commits kan herstellen die niet langer deel uitmaken van de branch-ancestry, kan git reflog helpen bij het herstellen van “verloren” commits door referentie-updates bij te houden, zelfs als die commits niet langer bereikbaar zijn vanaf een branch.

De onderstaande tabel vat deze belangrijke verschillen samen.

Git reflog is een krachtig hulpmiddel voor het herstellen van verloren commits en het oplossen van geschiedenisproblemen, maar effectief gebruik ervan vereist voorzichtigheid. Hier zijn enkele beste praktijken om te volgen bij het werken met reflog.

• Gebruik Reflog voor Herstel en Debugging: Als je per ongeluk een branch verkeerd hebt gereset of gerebased, controleer dan git reflog om een eerdere referentie te vinden en deze te herstellen.

• Wees Voorzichtig met git reset --hard: git reset --hard kan onomkeerbaar niet-geverifieerde wijzigingen verwijderen. Controleer altijd eerst de reflog om ervoor te zorgen dat je kunt herstellen als er iets misgaat.

• Houd Back-ups Voordat Je Vernietigende Commando’s Uitvoert: Om je te beschermen tegen gegevensverlies, implementeer geautomatiseerde back-ups van je Git-repositories. Bewaar back-ups altijd op een veilige, externe locatie om herstelbaarheid te garanderen in geval van hardwarefalen of andere rampen.

• Vertrouw Niet Alleen op Reflog voor Langetermijnherstel: Standaard worden reflog-vermeldingen gedurende 90 dagen bewaard. Na deze periode kunnen ze worden opgeschoond en onherstelbaar worden. Duw regelmatig uw commits naar een externe repository om ervoor te zorgen dat ze bewaard blijven buiten uw lokale reflog.

• Gebruik git reflog expire om Oude Invoeren te Beheren: Als de reflog van je repository rommelig wordt, snoei oudere of onbereikbare invoeren met git reflog expire.

Conclusie

Effectief het beheren van de geschiedenis van een project in Git vereist meer dan alleen basiscommando’s. Het verkennen van geavanceerde tools die referentie-updates bijhouden kan een waardevol vangnet bieden voor het herstellen van verloren commits, het herstellen van verwijderde branches en het corrigeren van fouten. Praktische ervaring met deze tools, samen met commando’s zoals git reset, git checkout en git revert, kan uw bekwaamheid in versiebeheer aanzienlijk verbeteren.

Onze cursussen volgen is niet alleen een geweldige manier om te leren, maar het is ook een geweldige manier om werkgevers te signaleren dat je softwareontwikkeling serieus neemt. Om die reden raad ik aan om onze Top 20 Git Sollicitatievragen en Antwoorden voor Alle Niveaus blogpost te bestuderen en onze nieuwe Git Fundamentals vaardighedenspoor te volgen om een expert te worden in alles wat met Git te maken heeft.