Übersicht
git reflog [show] [<ref>]
git reflog expire [--expire=<time>] [--all]
git reflog delete <entry>
Beschreibung
Der git reflog-Befehl zeigt die Historie, wohin jede Ref (HEAD, Branches) lokal gezeigt hat. Jede Bewegung — Commit, Checkout, Reset, Rebase — wird mit Zeitstempel und Grund protokolliert. Das Reflog ist Ihr Sicherheitsnetz: Selbst nach einer "destruktiven" Operation wie git reset --hard ist der vorherige Zustand wiederherstellbar, solange der Reflog-Eintrag überlebt (üblicherweise 90 Tage).
Refs im Reflog sind als HEAD@{2} ("HEADs Wert vor 2 Bewegungen") oder HEAD@{2.hours.ago} adressierbar. Um einen "verlorenen" Branch wiederherzustellen, finden Sie seinen alten SHA im Reflog und erstellen Sie einen neuen Branch von ihm.
Im täglichen Einsatz integriert sich git reflog eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git reflog --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.
Zu verstehen, wie git reflog mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git reflog hilft, alle drei zu vermeiden.
Häufige Optionen
| Option / Unterbefehl | Beschreibung |
|---|---|
show <ref> | Zeigt das Reflog für eine Ref (Standard HEAD). |
expire | Beschneidet alte Einträge. |
--expire=<time> | Lässt ältere Einträge ablaufen. |
--expire-unreachable=<time> | Für Commits, die von keiner Ref erreichbar sind. |
--all | Operiert auf jeder Ref. |
delete <entry> | Entfernt einen einzelnen Eintrag. |
Beispiele
git reflog
# Jüngste Bewegungen von HEAD
git reflog show feature/api
# Nur die Historie des Feature-Branches
git reset --hard HEAD@{1}
# Erholung von einem falschen Reset durch eine Bewegung zurück
git reflog expire --expire=30.days --all
# Reflog für jede Ref auf die letzten 30 Tage trimmen
Häufige Fehler
Reflogs sind NUR LOKAL — das Fetchen von einem Remote bringt deren Reflog nicht mit. Reflog-Einträge laufen schließlich ab; verlassen Sie sich nicht darauf für Langzeit-Wiederherstellung. git gc --prune=now nach dem Reflog-Ablauf auszuführen kann unerreichbare Commits dauerhaft entfernen.
Verwandte Befehle
git reset, git rebase, git fsck, git gc