Finden Sie einen verlorenen Commit mit Reflog

• Lesen Sie das Reflog als Aufzeichnung dieses Repositorys darüber, wo HEAD und Branches waren.
• Überprüfen Sie den Inhalt eines Kandidaten-Commits, bevor Sie ihn retten.
• Erstellen Sie beim gemessenen Commit einen Zweig, ohne ihn auszuchecken.
• Sagen Sie, was das Reflog nicht zurückbringen kann: nicht festgeschriebene Arbeit und abgelaufene Einträge.

Sie befinden sich auf private/lost-signup, einem Zweig aus dem Ergebnis M von Lektion 18. Sie haben eine Notiz festgeschrieben, „Dokumente: Bewahren Sie die Anmeldewiederherstellungsnotiz auf“, die docs/signup-recovery.md hinzugefügt hat, und haben dann einen Commit zurück einen Hard-Reset ausgeführt. Die Notiz ist aus der Filiale, aus der Grafik und aus Ihren Dateien verschwunden. Sie haben noch keinen Rettungszweig und haben sonst nichts geändert.

Alles ist lokal und im kostenlosen Plan (GitTree fordert Sie auf, sich anzumelden): kein Hosting-Konto, kein Anbieter, kein Internet. Jede Identität ist fiktiv (example.com). Führen Sie diese Lektion niemals in einem echten Projekt aus. Der Hard-Reset in der Vorbereitung ist eine Probe in einer Wegwerfkopie.

Nehmen Sie die Änderungen in GitTree oder mit den nativen Git-Befehlen vor, nicht beides in derselben Kopie. Das Ablesen des Ergebnisses ist immer sicher. Die Menübezeichnungen stammen aus den eigenen Strings von GitTree 2.0 und die nativen Befehle wurden mit Git 2.43 in Einwegkopien ausgeführt. Die GitTree-Schritte wurden nicht auf macOS, Windows oder Linux ausgeführt.

Das Reflog ist ein lokales Tagebuch der Ref-Bewegungen. HEAD hat einen, und jeder Zweig auch. Es zeichnet „Commit“, „Checkout“, „Reset“ und dergleichen auf, wobei das Commit jeweils auf dem gelandet ist. Ein anderer Klon hat Ihr Tagebuch nicht. Ein Commit, bei dem keine Zweignamen mehr existieren dürfen, und das Reflog ist, wie Sie es finden.

Selektoren wie HEAD@{1} zählen Einträge von jetzt an zurück, sodass sie sich bei jedem späteren Vorgang ändern. Lesen Sie die Aktion, die Zeit, den Ausweis und die Akte eines Kandidaten, bevor Sie ihn verwenden. Merken Sie sich einen Offset nicht als Rezept.

Das Reflog findet Commits, die gespeichert wurden. Es kann keine Bearbeitung gefunden werden, die nie festgeschrieben wurde, wie Lektion 27 gezeigt hat. Einträge verfallen: Standardmäßig behält Git Einträge für Commits, die kein Zweig erreicht, etwa dreißig Tage lang bei, und ein Repository kann dies ändern. Führen Sie während der Wiederherstellung keine Bereinigungs- oder Ablaufbefehle aus.

Durch das Erstellen eines Zweigs beim Commit wird eine Referenz hinzugefügt und sonst nichts. Der aktuelle Zweig, der Index und Ihre Dateien bleiben dort, wo sie sind.

Beginnen Sie mit einer separaten gewöhnlichen Kopie des Ergebnisses M aus Lektion 18 und lassen Sie Ihr Original unberührt. Erstellen Sie den Zweig, speichern Sie DOC_LOST, schreiben Sie ihn fest und setzen Sie einen Festschreibungsvorgang zurück. Dieses zerstörerische Präparat ist nur für eine Wegwerfkopie bestimmt.

Speichern Sie nur in der unten genannten Phase. Dabei handelt es sich um vollständige UTF-8/LF-Körper mit einem abschließenden Zeilenumbruch; Fügen Sie niemals Markdown-Zäune ein. Unveränderte ausführbare Dateien erben die benannte Eingabe. Versionen in separaten Varianten dürfen das Original nicht überschreiben.

docs/signup-recovery.md – DOC_LOST

# Recovered signup work

Keep a branch name before leaving useful experimental work.

Öffnen Sie die Palette mit Befehl+Umschalt+P (Strg+Umschalt+P bei Ubuntu).

1. Bauen Sie die Probe auf, wie im nächsten Abschnitt gezeigt, und notieren Sie sich das Thema des verlorenen Commits.
2. Öffnen Sie die Palette und führen Sie View Reflog… aus. Der Dialog „Reflog“ wird geöffnet, wobei Reflog of auf HEAD gesetzt ist; Die neuesten Einträge werden zuerst aufgelistet.
3. Lesen Sie die Top-Einträge. Die neueste Version lautet „Zurücksetzen“ und die darunter liegende Version lautet „Commit“ mit dem Betreff „Dokumente: Bewahren Sie die Wiederherstellungsnotiz für die Anmeldung auf“. Verwenden Sie Show Older Entries, wenn die Liste lang ist. Gehen Sie nicht davon aus, dass die zweite Reihe immer die richtige ist.
4. Wählen Sie den Commit-Eintrag aus. Das Dialogfeld zeigt Show in Graph und New branch name. Show in Graph kann nur einen Commit platzieren, den ein Zweig erreicht. Daher wird für diesen verlorenen Commit der Dialog geschlossen und das Diagramm bleibt auf M: Öffnen Sie das Reflog erneut für den nächsten Schritt. Sie lesen die Datei des Commits, nachdem Sie sie wiederhergestellt haben.
5. Zurück im Dialog wählen Sie denselben Eintrag aus, geben rescue/signup in New branch name ein und wählen Restore as Branch. In der Benachrichtigung steht: „Zweigrettung/Anmeldung erstellt. Durch Rückgängigmachen wird es wieder entfernt.“
6. Überprüfen Sie das Ergebnis: rescue/signup zeigt auf den verlorenen Commit, der aktuelle Zweig ist immer noch private/lost-signup auf M und Ihre Dateien bleiben unverändert. Wählen Sie den wiederhergestellten Commit aus und öffnen Sie seine Datei docs/signup-recovery.md: Sie lautet DOC_LOST.
7. Lassen Sie den Rettungszweig an Ort und Stelle. Führen Sie keine Bereinigung durch, um das Diagramm aufzuräumen.

Für jeden gewöhnlichen Commit im Kurs: Summary ist das angegebene Subjekt, Description ist leer und die Optionen Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit und Allow Empty Commit bleiben ausgeschaltet.

Nur in einer separaten, sauberen Kopie des Ergebnisses von Lektion 18:

git switch --create private/lost-signup

Speichern Sie DOC_LOST als docs/signup-recovery.md, dann:

git add -- docs/signup-recovery.md
git commit --quiet -m "docs: keep the signup recovery note"
git reset --hard HEAD~1
git reflog show --format=%gs -2 HEAD

reset: moving to HEAD~1
commit: docs: keep the signup recovery note

Listen Sie die Kandidaten mit ihren Ausweisen auf und überprüfen Sie den, den Sie für verloren halten:

git reflog show --format='%H %gs' HEAD
git show "<lost-sha>:docs/signup-recovery.md"

Ersetzen Sie <lost-sha> durch die ID in der Zeile „commit: docs: keep the signup Recovery Note“. In diesem unmittelbaren Beispiel ist HEAD@{1} derselbe Commit, aber dieser Offset ist keine Regel. Erstellen Sie den Rettungszweig, ohne ihn auszuchecken:

git branch rescue/signup "<lost-sha>"
git show rescue/signup:docs/signup-recovery.md
git symbolic-ref --short HEAD
git status --short

Die Datei ist DOC_LOST, der gedruckte Zweig ist private/lost-signup und der Status ist leer. In Ihren Dateien wird der Hinweis nicht angezeigt, da HEAD auf M verblieben ist. Hierzu gehört kein Ablauf- oder Bereinigungsbefehl.

Where you end: rescue/signup zeigt auf den verlorenen Commit und seine Datei ist DOC_LOST. Der aktuelle Zweig, der Index und Ihre Dateien sind genau so, wie sie nach dem Zurücksetzen waren, und es wurde nichts gepusht.

• HEAD@{1} als festes Rezept verwenden, anstatt den Eintrag zu lesen.
• Durch Zurücksetzen oder erneutes Auschecken vor dem Speichern eines Zweigs werden weitere Einträge hinzugefügt und der gewünschte vergraben.
• Es wird erwartet, dass das Reflog eine Bearbeitung enthält, die nie festgeschrieben wurde.
• Bereinigungsbefehle ausführen, während nach etwas gesucht wird.

Wenn der Commit nicht in der Liste enthalten ist, suchen Sie möglicherweise nach der falschen Referenz: Wechseln Sie Reflog of zwischen HEAD und dem Zweig und verwenden Sie Show Older Entries. Wenn es wirklich weg ist, ist es abgelaufen oder wurde nie festgeschrieben. In der App lautet der Hinweis nach Restore as Branch, dass „Rückgängig“ den Zweig wieder entfernt.

Beantworten Sie jede Frage und lesen Sie dann, warum. Mit „erforderlich“ gekennzeichnete Fragen zählen zum Abschluss der Lektion.

1. Frage 1 von 6

   Frage 1 von 6

   Was ist das Reflog?

   Wählen Sie eine Antwort.

   Ein gemeinsames Protokoll, das jeder Klon und der Server im Gleichschritt halten.

   Eine Sicherung Ihrer Dateien.

   Eine lokale Aufzeichnung darüber, wohin HEAD und jeder Zweig gezeigt haben.

   Das Gleiche wie das Commit-Diagramm.

   Antwort prüfen
2. Frage 2 von 6

   Frage 2 von 6

   Welche davon treffen auf das Reflog zu?

   Wählen Sie jede zutreffende Antwort aus.

   Es speichert Änderungen, die Sie nie vorgenommen haben.

   HEAD und jeder Zweig haben ihre eigenen.

   Alte Einträge verfallen.

   Ein anderer Klon des Projekts verfügt nicht über Ihre Einträge.

   Antwort prüfen
3. Frage 3 von 6

   Frage 3 von 6Erforderlich

   Sie haben den verlorenen Commit im Reflog gefunden und Restore as Branch mit dem Namen rescue/signup verwendet. Was siehst du?

   Wählen Sie eine Antwort.

   rescue/signup zeigt auf den verlorenen Commit, und Sie befinden sich immer noch auf private/lost-signup bei M und Ihre Dateien bleiben unverändert.

   Sie befinden sich jetzt auf rescue/signup und die Notiz ist wieder in Ihren Dateien.

   private/lost-signup geht weiter zum verlorenen Commit.

   Der Reflog-Eintrag wird gelöscht.

   Antwort prüfen
4. Frage 4 von 6

   Frage 4 von 6

   Ändern Sie die Eingabe: Sie haben die Notiz nie festgeschrieben und dann den Hard-Reset ausgeführt. Kann der Reflog es zurückbringen?

   Wählen Sie eine Antwort.

   Ja, über „Ältere Einträge anzeigen“.

   Ja, mit HEAD@{1}.

   Nein. Das Reflog verweist auf Commits, und dieser Inhalt befand sich nie in einem solchen.

   Ja, indem Sie Reflog auf den Zweig umstellen.

   Antwort prüfen
5. Frage 5 von 6

   Frage 5 von 6Erforderlich

   Sie haben ein paar weitere Vorgänge ausgeführt und dann git branch rescue HEAD@{1} ausgeführt, und die Datei ist nicht die gewünschte. Was ist passiert?

   Wählen Sie eine Antwort.

   HEAD@{1} ist nach einem Reset immer der richtige Commit.

   Das Reflog ist beschädigt.

   Der verlorene Commit wurde vom neuen Zweig gelöscht.

   HEAD@{1} zählt von jetzt an zurück, sodass jeder neue Vorgang seinen Namen ändert. Lesen Sie die Liste und verwenden Sie die ID des verlorenen Commits.

   Antwort prüfen
6. Frage 6 von 6

   Frage 6 von 6Erforderlich

   Welche Readbacks zeigen, nachdem Sie den Rettungszweig erstellt haben, dass er wie in der Lektion beschrieben funktioniert hat?

   Wählen Sie jede zutreffende Antwort aus.

   docs/signup-recovery.md ist jetzt in Ihren Dateien vorhanden.

   git show rescue/signup:docs/signup-recovery.md druckt die wiederhergestellte Notiz, beginnend mit „# Wiederhergestellte Anmeldearbeit“.

   git status --short gibt nichts aus.

   git symbolic-ref --short HEAD gibt private/lost-signup aus.

   Antwort prüfen

Melden Sie die beiden neuesten Reflog-Zeilen, die ID des verlorenen Commits, die erste Zeile der wiederhergestellten Datei und den Zweig, in dem sich Ihr Checkout befindet. Sagen Sie dann, was das Reflog für eine Änderung anzeigen würde, die Sie nie vorgenommen haben.

• Das Reflog ist ein lokales Tagebuch der Schiedsrichterbewegungen.
• Überprüfen Sie den Kandidaten und verzweigen Sie dann von ihm.
• Es findet Commits, keine nicht gespeicherten Änderungen.

• Zurücksetzen: weich, gemischt und hart (Lektion 27)
• Verlauf lesen, ohne HEAD zu bewegen (Lektion 8)
• Laden Sie GitTree herunter

Reflog – سجل المراجع; Rettungszweig – فرع حفظ; Selektor – محدِّد.