Verwenden des Reflogs, um verlorene Commits wiederherzustellen

Dieser Artikel ist Teil der "Advanced Git" -Serie. Folgen Sie uns auf Twitter oder melden Sie sich für unseren Newsletter an, um sich zukünftigen Artikeln anzusehen!

Gits "Reflog" -Feature ist wenig bekannt, aber sehr praktisch. Einige Leute nennen es ein "Sicherheitsnetz" und ich betrachte es lieber als "Tagebuch" von Git. Dies liegt daran, dass Git es benutzt, um jeden Bewegungsbewegung des Kopfzeigers aufzuzeichnen (d. H. Jedes Komitee, Zusammenführen, Wiederherstellen, Auswahl, Zurücksetzen usw.). Git protokolliert Ihre Aktionen im Reflog, macht es zu einem wertvollen Logbuch und zu einem guten Ausgangspunkt, wenn Probleme auftreten.

Im letzten Teil dieser "Advanced Git" -Serie werde ich den Unterschied zwischen git log und git reflog erklären und Ihnen zeigen, wie Sie Reflog verwenden, um gelöschte Commits und löschte Zweige wiederherzustellen.

Erweiterte Git -Serie:

• Teil 1: Erstellen Sie einen perfekten Verpflichtung in Git
• Teil 2: Verzweigungsstrategien in Git
• Teil 3: Bessere Zusammenarbeit durch Pull -Anfragen
• Teil 4: Zusammenschlusskonflikt
• Teil 5: Basis und Fusion ändern
• Teil 6: Interaktive Basisänderung
• Teil 7: Wählen Sie Einsendungen in Git aus
• Teil 8: Erholen Sie verlorene Commits mit Reflog ( Sie sind jetzt hier! )

git log oder git reflog : Was ist der Unterschied?

In früheren Beiträgen schlug ich vor, dass Sie den Befehl git log verwenden, um frühere Ereignisse zu überprüfen und Ihren Commit -Historie anzusehen, genau das ist das, was er tut. Es zeigt den aktuellen Kopf und seine Vorfahren an, d. H. Sein Elternteil, das nächste Elternteil usw. Die Protokolle verfolgen auf den Beginn der Lit -Geschichte, indem sie die Eltern jedes Commits rekursiv drucken. Es ist Teil des Repositorys, was bedeutet, dass es kopiert wird, nachdem Sie gedrückt, abgeholt oder gezogen werden.

Auf der anderen Seite ist git reflog ein privater Arbeitsbereich. Es iteriert nicht über die Liste der Vorfahren. Stattdessen wird eine geordnete Liste aller Commits angezeigt, auf die der Kopf in der Vergangenheit hingewiesen wurde. Deshalb können Sie es als eine Art "Rückgängiggeschichte" betrachten, wie Sie es in Textprozessoren, Textredakteuren usw. sehen, etc.

Dieser lokale Datensatz ist technisch nicht Teil des Repositorys und wird getrennt vom Commit gespeichert. Reflog ist eine Datei in .git/logs/refs/heads/ die die lokalen Commits jeder Niederlassung verfolgt. Die Tagebücher von Git werden normalerweise nach 90 Tagen gereinigt (dies ist der Standard), aber Sie können das Ablaufdatum des Reflogs problemlos anpassen. Um die Anzahl der Tage auf 180 zu ändern, geben Sie einfach den folgenden Befehl ein:

 $ git config gc.reflogexpire 180.days.ago

Alternativ können Sie entscheiden, dass Ihr Reflog niemals ablaufen wird:

 $ git config gc.reflogexpire niemals

Tipp: Denken Sie daran, dass Git die Konfigurationsdateien des Repository ( .git/config ), die globale Benutzerkonfiguration ( $HOME/.gitconfig ) und systemweite Einstellungen ( /etc/gitconfig ) unterscheidet. Um das Reflog -Ablaufdatum des Benutzers oder des Systems anzupassen, fügen Sie dem oben gezeigten Befehl --system oder --global anzupassen.

Genug theoretischer Hintergrund - lassen Sie mich Ihnen zeigen, wie Sie git reflog verwenden, um Fehler zu korrigieren.

Erholen Sie gelöschte Commits

Stellen Sie sich das folgende Szenario vor: Nachdem Sie sich die Verpflichtung angesehen haben, entscheiden Sie sich, die letzten beiden Commits zu löschen. Sie haben mutig ausgeführt, git reset , und die beiden Commits verschwanden aus der Festungsgeschichte ... Nach einer Weile bemerkten Sie, dass dies ein Fehler war. Sie haben gerade Ihre wertvollen Veränderungen verloren und Panik begonnen!

Müssen Sie wirklich von vorne anfangen? Keine Notwendigkeit. Mit anderen Worten: Bleib ruhig und benutze git reflog !

Lassen Sie uns also die Dinge vermasseln und diesen Fehler im wirklichen Leben machen. Das nächste Bild zeigt unseren ursprünglichen Commit -History im Tower (ein grafischer Git -Client):

Wir möchten die beiden Commits löschen und die Änderung und Abdrucktitelkomite (ID: 2B504Bee) als letzte Revision in unserer Master -Filiale festlegen. Wir kopieren einfach die Hash -ID in die Zwischenablage, verwenden dann git reset in der Befehlszeile und geben diesen Hash -Wert ein:

 $ Git Reset --Hard 2b504bee

Sehen! Die Einreichung verschwand. Nehmen wir nun an, dies ist ein Fehler und schauen Sie sich das Reflog an, um die verlorenen Daten wiederherzustellen. Geben Sie git reflog , um das Journal in Ihrem Terminal anzuzeigen:

Sie werden feststellen, dass alle Einträge in chronologischer Reihenfolge angeordnet sind. Dies bedeutet: Das neueste Commit ist an der Spitze. Und wenn Sie genau hinschauen, werden Sie den tödlichen git reset -Betrieb vor einigen Minuten feststellen.

Das Tagebuch scheint zu funktionieren - das sind gute Nachrichten. Verwenden wir es also, um die letzte Aktion rückgängig zu machen und den Status vor dem Befehl Reset wiederherzustellen. Kopieren Sie wie zuvor die Hash -ID (E5B19E4 in diesem speziellen Beispiel) in die Zwischenablage. Sie können git reset erneut verwenden, was perfekt funktioniert. Aber in diesem Fall werde ich einen neuen Zweig erstellen, der auf dem alten Zustand basiert:

 $ Git Branch Happy-End E5B19E4

Schauen wir uns unseren grafischen Git -Kunden erneut an:

Wie Sie sehen, wurde eine neue Niederlassung namens Happy End mit unseren zuvor gelöschten Commits erstellt-großartig, nichts ist verloren!

Schauen wir uns ein anderes Beispiel an und verwenden Sie Reflog, um den gesamten Zweig wiederherzustellen.

Löschte Zweige wiederherstellen

Das nächste Beispiel ähnelt unserem ersten Szenario: Wir werden etwas löschen - diesmal der gesamte Zweig. Vielleicht fordert Ihr Kunde oder Teamleiter auf, eine Feature -Filiale zu löschen. Vielleicht ist es die Idee, sich selbst aufzuräumen. Schlimmer noch, ein Commit (C3 auf dem Bild) ist in keiner anderen Filiale enthalten, sodass Sie definitiv Daten verlieren:

Lassen Sie uns dies tatsächlich tun und dann den Zweig später wiederherstellen:

Sie müssen es lassen, bevor Sie feature/login löschen können. (Wie im Screenshot gezeigt, ist es der aktuelle Kopfzweig, Sie können den Head -Zweig in Git nicht löschen.) Daher wechseln wir den Zweig (zum Master) und löschen dann feature/login :

Ok ... nun nehmen wir an, dass unser Kunde oder Teamleiter seine Meinung geändert hat. Schließlich sind feature/login -Zweige (einschließlich ihrer Commits) erforderlich. Was sollen wir tun?

Schauen wir uns Gits Tagebuch an:

 $ Git Reflog
776f8ca (Head -> Master) Head@{0}: Kasse: Verschieben von Feature/Login zu Master
B1C249B (Feature/Login) Head@{1}: Kasse: Verschieben von Master zu Funktion/Anmeldung
[...]

Wir haben uns wieder als Glück erwiesen. Der letzte Eintrag zeigt, wie wir von feature/login auf Master wechseln. Versuchen wir, in den vorherigen Zustand zurückzukehren und die Hash -ID B1C249B in die Zwischenablage zu kopieren. Als nächstes erstellen wir eine Filiale mit dem Namen feature/login basierend auf dem erforderlichen Status:

 $ Git Branch Feature/Login B1C249b
$ Git Branch -vv
  Feature/Login B1C249B Änderung iPrint -Seiten -Titel
* Master 776f8ca Änderung zum Titel und Löschen der Fehlerseite

Großartig - Der Zweig erholt sich vom Tod und enthält auch wertvolle Commits, die wir als verloren betrachten:

Wenn Sie Git in einem Desktop -GUI -Turm verwenden, können Sie Ihre letzte Aktion rückgängig machen, indem Sie CMD Z wie einen Text -Editor oder ein Textverarbeitungsprogramm drücken, wenn Sie einen Fehler eingeben.

Bleib ruhig und behalte den Überblick

Gits Reflog kann ein echter Retter sein! Wie Sie sehen können, ist es sehr einfach, fehlende Commits aus dem Grab oder sogar dem gesamten Zweig zu entfernen. Alles, was Sie tun müssen, ist die richtige Hash -ID im Reflog zu finden - der Rest ist ein Kinderspiel.

Wenn Sie sich mit fortgeschrittenen Git -Tools befassen möchten, lesen Sie Ihre (kostenlosen!) Erweitertes Git -Toolkit an: Es handelt sich um eine Sammlung von kurzen Videos zu Themen wie Verzweigungsstrategien, interaktive Rebasen, Refrogel, Submodules und mehr.

Dies ist der letzte Teil unserer "Advanced Git" -Serie über CSS-Tricks. Ich hoffe, Sie haben diese Artikel genossen. Glücklicher Hacker!

Erweiterte Git -Serie:

• Teil 1: Erstellen Sie einen perfekten Verpflichtung in Git
• Teil 2: Verzweigungsstrategien in Git
• Teil 3: Bessere Zusammenarbeit durch Pull -Anfragen
• Teil 4: Zusammenschlusskonflikt
• Teil 5: Basis und Fusion ändern
• Teil 6: Interaktive Basisänderung
• Teil 7: Wählen Sie Einsendungen in Git aus
• Teil 8: Erholen Sie verlorene Commits mit Reflog ( Sie sind jetzt hier! )

Das obige ist der detaillierte Inhalt vonVerwenden des Reflogs, um verlorene Commits wiederherzustellen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!