Git Reflog: Verstehen und Verwenden von Referenzprotokollen in Git

Es gibt nichts Frustrierenderes für einen Entwickler oder Dateningenieur, als versehentlich Git-Branches zu löschen oder Commits zurückzusetzen, wenn man das nicht wollte. Deshalb freue ich mich, etwas zu teilen, das ich aus eigener Erfahrung gelernt habe und das ich mir gewünscht hätte, früher gelernt zu haben, nämlich wie man git reflog verwendet. git reflog ist eine dieser Techniken, die sich auf jeden Fall lohnt zu lernen; wenn Sie jetzt ein wenig Zeit investieren, können Sie sich später viel Kopfzerbrechen ersparen.

Während ich Ihnen git reflog zeigen werde, das ich als sehr hilfreich empfinde, um Fehler zu navigieren und sich davon zu erholen, möchte ich auch unsere Grundlagen von Git und Einführung in GitHub-Konzepte Kurse empfehlen, um alles über Versionskontrolle zu lernen.

Was ist git reflog?

Git reflog, oder Referenzprotokoll, ist ein lokaler Tracking-Mechanismus, der Updates zu Branch-Spitzen und dem HEAD-Referenz in einem Git-Repository aufzeichnet. (Im Kontext von Git bezieht sich HEAD auf den aktuellen Commit, auf dem Ihr Arbeitsverzeichnis und der Staging-Bereich basieren.)

Im Gegensatz zu git log, das die Commit-Historie basierend auf der Abstammung anzeigt und zeigt, wie Commits in einem Branch verbunden sind, erfasst git reflog alle Bewegungen von HEAD, einschließlich Branch-Wechsel, Rebases, Resets und Commits. Dies macht reflog nützlich, um verlorene Commits wiederherzustellen und kürzliche Aktionen zu debuggen.

Wann werden reflog-Einträge erstellt?

Reflog-Einträge werden erstellt, wenn Sie Aktionen ausführen, die den Zustand von HEAD oder Branch-Verweisen ändern. Zu den häufigen Szenarien gehören folgende:

• Änderungen mit git commit bestätigen.

• Ein anderes Branch mit git checkout branch_name auschecken.

• Einen neuen Branch mit git branch new_branch erstellen.

• Rebasen mit git rebase

• Auf einen früheren Commit zurücksetzen mit git reset --hard.

• Branches mit git merge zusammenführen.

Hier ist der Code, den Sie verwenden, um Aktualisierungen im lokalen Repository zu verfolgen:

git reflog

Verwenden von git reflog, um Aktualisierungen im lokalen Repository zu verfolgen. Bild von Autor.

Wie interpretieren Sie die Ausgabe von git reflog?

Sie können die Ausgabe wie folgt interpretieren:

• HEAD@{0}: Die letzte Aktion bestand darin, zum HEAD-Branch zu wechseln.

• HEAD@{1}: Davor hatte ich den Dateityp von .xlxs in das Format .csv geändert.

• HEAD@{2}: Ich habe den ersten Commit gemacht, als ich die Dateien im Repository gepusht habe.

Jeder Eintrag zeigt:

• Der Commit-Hash (fa82776)

• Der Reflog-Index (HEAD@{0}, HEAD@{1} usw.)

• Eine Beschreibung der durchgeführten Aktion (Commit, Checkout, Rebase)

Wie man git reflog verwendet

Git reflog bietet eine Möglichkeit, Referenzaktualisierungen nachzuverfolgen und die vorherigen Zustände Ihres Repositorys wiederherzustellen. Indem Sie verstehen, wie Sie durch die Reflog-Einträge navigieren können, können Sie verlorene Commits wiederherstellen, Änderungen rückgängig machen und vergangene Versionen Ihrer Arbeit vergleichen.

Grundlegender Git-Reflog-Befehl

Im Folgenden finden Sie den grundlegenden Reflog-Befehl:

git reflog

Der oben genannte Befehl zeigt eine Liste der kürzlichen Aktionen an, die HEAD oder Branch-Referenzen aktualisiert haben, einschließlich Commits, Branch-Wechsel, Resets, Rebasen und mehr. Jeder Eintrag ist indiziert, z. B. HEAD@{0} und HEAD@{1}, um seine Position im Reflog-Verlauf darzustellen.

Referenzierung vergangener Zustände

Git reflog dient als Aufzeichnung vergangener Referenzaktualisierungen, die es uns ermöglicht, frühere Punkte in der Historie unseres Repositories zu lokalisieren und wiederherzustellen. Ohne sie würden diese Referenzen nicht existieren, und wir bräuchten genaue Commit-Hashes, um zu bestimmten vergangenen Zuständen zurückzukehren. Nun wollen wir erkunden, wie Git es uns ermöglicht, diese vergangenen Zustände mithilfe von git checkout zu durchlaufen.

HEAD@{n}: Verweist auf einen bestimmten Eintrag im Reflog, wobei n der Index ist. Zum Beispiel verweist HEAD@{2} auf den drittletzten Zustand von HEAD.

git checkout HEAD@{2}

Verwendung von git checkout zur Verfolgung vergangener Änderungen. Bild von Autor.

branch@{time}: Bezieht sich auf den Zustand eines Branches zu einem bestimmten Zeitpunkt. Zum Beispiel bezieht sich main@{1.week.ago} auf den Zustand des Hauptbranches vor einer Woche, während sich feature@{yesterday} auf den Zustand des Feature-Branches gestern bezieht.

git checkout main@{1.week.ago}

Die Verwendung von git checkout zur Verfolgung vergangener Änderungen. Bild von Autor.

Zeitbasierte Qualifikatoren

git reflog hilft uns nicht nur dabei, vergangene Zustände wiederherzustellen, sondern ermöglicht es uns auch, sie zu vergleichen. Da reflog Referenzaktualisierungen verfolgt, können wir damit sehen, wie sich unser Repository im Laufe der Zeit verändert hat. Schauen wir uns nun an, wie git diff Reflog-Einträge verwendet, um vergangene und aktuelle Zustände zu vergleichen.

Die folgenden Beispiele für Zeitqualifikatoren erleichtern es, Ihr Repository zu einem bestimmten Zeitpunkt wiederherzustellen, anstatt sich ausschließlich auf Reflog-Indexnummern zu verlassen.

git checkout HEAD@{1.minute.ago}     # Zustand von vor einer Minute

git checkout HEAD@{1.hour.ago}       # Zustand von vor einer Stunde

git checkout HEAD@{1.week.ago}       # Zustand von vor einer Woche

git checkout HEAD@{yesterday}        # Stand von gestern

git checkout HEAD@{2024-01-01.12:00:00} # Stand zu einem bestimmten Zeitpunkt

Vergleich vergangener Zustände mit git diff

Sie können vergangene Zustände mit Befehlen wie git diff vergleichen. Der folgende Befehl vergleicht den aktuellen Zustand des Hauptzweigs main@{0} mit seinem Zustand von vor einem Tag, main@{1.day.ago}. Die Ausgabe zeigt eventuelle Unterschiede zwischen diesen beiden Momentaufnahmen.

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

Vergleich vergangener Zustände mit git diff. Bild von Autor.

Gängige Anwendungsfälle für Git Reflog

Git Reflog ist ein unschätzbares Werkzeug, um verlorene Änderungen wiederherzustellen, Fehler rückgängig zu machen und gängige Git-Pannen zu beheben. Nachfolgend sind einige praktische Szenarien aufgeführt, in denen git reflog helfen kann.

Rückgängigmachen eines schlechten Resets

Wenn Sie Ihren Zweig versehentlich mit git reset --hard zurückgesetzt haben, können Sie Reflog verwenden, um Ihren vorherigen Zustand wiederherzustellen.

git reset --hard HEAD@{3}

Wiederherstellen verlorener Commits

Wenn Sie versehentlich einen Branch löschen oder Commits aufgrund eines Resets oder Rebase verlieren, können Sie den verlorenen Commit mit git reflog finden.

git reflog

Suchen Sie den Commit-Hash aus der Reflog-Ausgabe und checken Sie ihn aus:

git checkout <commit-hash>

Nachdem Sie den verlorenen Commit überprüft haben, können Sie einen neuen Branch erstellen, um ihn zu erhalten:

git branch recovered-branch <commit-hash>

Beheben eines fehlerhaften Rebase

Wenn ein Rebase schiefgeht, können Sie git reflog verwenden, um den Commit vor dem Rebase zu finden und Ihren Branch zurückzusetzen. Identifizieren Sie den Commit vor dem Rebase und setzen Sie ihn zurück.

git reset --hard HEAD@{3}  # Passen Sie die Nummer basierend auf der Reflog-Ausgabe an

Wiederherstellen eines gelöschten Branches

Wenn Sie versehentlich einen Branch löschen, können Sie ihn mithilfe von git reflog wiederherstellen. Finden Sie den letzten bekannten Commit des gelöschten Branches und erstellen Sie ihn neu:

git branch restored-branch <commit-hash>

Stash-Verlauf nachverfolgen

Git reflog kann auch verwendet werden, um den Stash-Verlauf anzuzeigen. Der folgende Befehl listet Stash-Operationen auf und ermöglicht es Ihnen, ältere Stashes bei Bedarf wiederherzustellen. 

git reflog stash

Um einen früheren Stash-Eintrag anzuwenden, verwenden Sie den folgenden Befehl:

git stash apply stash@{2}

Schauen Sie sich unser Tutorial zu Git Pull Force: So überschreiben Sie einen lokalen Branch mit Remote an, um bewährte Praktiken zum Überschreiben lokaler Änderungen zu erlernen.

Git Reflog-Unterbefehle und Optionen

Git bietet mehrere Unterbefehle und Optionen zum Verwalten und Interagieren mit Reflogs.

Git Reflog-Unterbefehle

Im Folgenden finden Sie eine strukturierte Aufschlüsselung der wichtigsten git reflog-Unterbefehle und ihrer Verwendung.

git reflog show: Zeigt standardmäßig die Reflog-Einträge für HEAD an oder für eine angegebene Referenz wie einen Branch.

git reflog show

Mit git reflog show werden Einträge für den angegebenen Verweis angezeigt. Bild von Autor.

git reflog list: Dieser Befehl zeigt alle Verweise mit einem Reflog an. Er ist nützlich, um Zweige und HEAD-Verweise mit gespeicherten Reflog-Einträgen zu identifizieren.

git reflog list

git reflog delete <ref>@{<specifier>}: Löscht alte Reflog-Einträge, die das angegebene Zeitlimit überschreiten. Zum Beispiel entfernt der folgende Befehl Einträge, die älter als 30 Tage sind.

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

git reflog delete <ref>@{<specifier>}: Löscht einen bestimmten Reflog-Eintrag basierend auf seinem Verweis und seiner Position. Der folgende Befehl entfernt den Reflog-Eintrag am Index 2 für HEAD.

git reflog delete HEAD@{2}

git reflog exists <ref>: Überprüft, ob ein Reflog für eine bestimmte Referenz vorhanden ist. Zum Beispiel gibt der folgende Befehl erfolgreich zurück, wenn der Hauptzweig ein Reflog hat.

git reflog exists main

Optionen für git reflog-Unterbefehle

Die folgenden Optionen sind für die git reflog-Unterbefehle verfügbar und deren Verwendung.

--expire-unreachable=<time>: Löscht nur diejenigen Reflog-Einträge, die von keiner Referenz aus erreichbar sind. Zum Beispiel entfernt der folgende Befehl unerreichbare Reflog-Einträge, die älter als 7 Tage sind.

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

--all: Verarbeitet Reflogs für alle Referenzen, nicht nur für HEAD. Der Befehl unten räumt alle Reflogs älter als 60 Tage in allen Zweigen auf.

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

--dry-run: Simuliert die Ausführung eines Befehls und zeigt, was gelöscht würde, ohne tatsächlich etwas zu löschen. Zum Beispiel zeigt der folgende Befehl, welche Einträge entfernt würden.

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

--verbose: Bietet detaillierte Ausgaben zu den von dem Befehl ausgeführten Aktionen. Der folgende Befehl zeigt ausführliche Details beim Ablaufen alter Reflog-Einträge.

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

Git Reflog vs. Git Log: Hauptunterschiede

Sowohl git log als auch git reflog geben Einblicke in die Historie eines Repositorys, haben jedoch unterschiedliche Zwecke. Schauen wir uns diese Unterschiede an, um zu verstehen, wie jeder für die Versionskontrolle und Wiederherstellungsstrategien verwendet werden kann.

• git log zeigt die Commit-Historie, indem es die Verwandtschaft von Commits in einem Branch verfolgt. Es bietet einen chronologischen Überblick darüber, wie sich der Inhalt des Repositorys entwickelt hat.

• git reflog protokolliert Aktualisierungen von Referenzen wie HEAD, Branches und Stashes, einschließlich Aktionen wie Branch-Wechsel, Resets, Rebasen und mehr. Es verfolgt Änderungen, die möglicherweise nicht Teil der Commit-Abstammung sind.

• git reflog ist streng lokal auf Ihrer Maschine und wird nicht mit Remote-Repositories geteilt.

• Während git log Commits, die nicht mehr Teil der Zweig-Herkunft sind, nicht wiederherstellen kann, kann git reflog „verlorene“ Commits wiederherstellen, indem es Referenzaktualisierungen verfolgt, auch wenn diese Commits nicht mehr von einem Zweig erreichbar sind.

Die Tabelle unten fasst diese wesentlichen Unterschiede zusammen.

Git Reflog ist ein leistungsstolles Werkzeug zur Wiederherstellung verlorener Commits und zur Behebung von Historieproblemen, erfordert aber Vorsicht bei der effektiven Nutzung. Hier sind einige bewährte Verfahren, die beim Arbeiten mit Reflog zu befolgen sind.

• Verwenden Sie Reflog zur Wiederherstellung und Fehlerbehebung: Wenn Sie einen Branch versehentlich falsch zurücksetzen oder rebaseen, überprüfen Sie git reflog, um einen vorherigen Verweis zu finden und wiederherzustellen.

• Seien Sie vorsichtig mit git reset --hard: git reset --hard kann nicht gespeicherte Änderungen dauerhaft entfernen. Überprüfen Sie immer zuerst den Reflog, um sicherzustellen, dass Sie wiederherstellen können, wenn etwas schief geht.

• Erstellen Sie Backups, bevor Sie zerstörerische Befehle ausführen: Zum Schutz vor Datenverlust sollten Sie automatisierte Backups Ihrer Git-Repositorys implementieren. Speichern Sie Backups immer an einem sicheren, externen Ort, um die Wiederherstellbarkeit im Falle eines Hardwareausfalls oder anderer Katastrophen zu gewährleisten.

• Verlassen Sie sich nicht ausschließlich auf Reflog für die langfristige Wiederherstellung:Standardmäßig werden Reflog-Einträge für 90 Tage aufbewahrt. Nach diesem Zeitraum können sie gelöscht und nicht mehr wiederhergestellt werden. Drücken Sie regelmäßig Ihre Commits in ein Remote-Repository, um sicherzustellen, dass sie über Ihren lokalen Reflog hinaus erhalten bleiben.

• Verwenden Sie git reflog expire zur Verwaltung alter Einträge: Wenn der Reflog Ihres Repositories überfüllt wird, entfernen Sie ältere oder unerreichbare Einträge mit git reflog expire.

Conclusion

Es erfordert mehr als nur grundlegende Befehle, um die Projektgeschichte in Git effektiv zu verwalten. Die Erkundung fortgeschrittener Tools, die Referenzaktualisierungen verfolgen, kann ein wertvolles Sicherheitsnetz bieten, um verlorene Commits wiederherzustellen, gelöschte Branches wiederherzustellen und Fehler zu korrigieren. Die praktische Erfahrung mit diesen Tools sowie Befehlen wie git reset, git checkout und git revert kann Ihre Kenntnisse in der Versionskontrolle erheblich verbessern.

Den Besuch unserer Kurse zu absolvieren ist nicht nur eine großartige Möglichkeit zu lernen, sondern auch eine großartige Möglichkeit, Arbeitgebern zu signalisieren, dass Sie die Softwareentwicklung ernst nehmen.. Zu diesem Zweck empfehle ich, unseren Blog-Beitrag Top 20 Git Interview Fragen und Antworten für alle Levels zu studieren und unseren neuen Skill-Track Git-Grundlagen zu absolvieren, um ein Experte in allen Git-relevanten Themen zu werden.