Git-Reset, Rebase und Commits rückgängig machen: So stellen Sie (fast) alles in Git wieder her

Um einen Git-Reset, ein Rebase oder ein Commit rückgängig zu machen, führen Sie git reflog aus, suchen Sie den Eintrag direkt vor dem Fehler und verweisen Sie Ihren Branch wieder darauf, zum Beispiel mit git reset --hard HEAD@{1}. Git protokolliert jede Bewegung von HEAD und jedem Zweig im Reflog und behält standardmäßig sogar den Eintrag eines verlorenen Commits 30 Tage lang (90 Tage für Commits, die sich noch in einem Zweig befinden), sodass festgeschriebene Arbeit fast nie verloren geht. Die einzige wirkliche Ausnahme sind Arbeiten, die Sie nie begangen haben.

Nachfolgend finden Sie das Rezept für jeden häufigen Fehler. Jeder Befehl ist reines Git und funktioniert auf macOS, Windows und Linux gleich. Führen Sie sie auf Windows in Git Bash aus, das mit Git for Windows geliefert wird: PowerShell benötigt Reflog-Namen wie HEAD@{1} in Anführungszeichen und hat kein grep. Am Ende werden Sie sehen, wie GitTree, ein Desktop-Git-Client, einen Wiederherstellungs-Snapshot für 19 Arten von Vorgängen erstellt, sodass die meisten Fehler mit einem Klick behoben werden.

Git-Spickzettel rückgängig machen: Der Befehl für jeden Fehler

Finden Sie Ihre Situation heraus und lesen Sie dann den Abschnitt, bevor Sie etwas ausführen. HEAD@{1} bedeutet „wo HEAD vor einem Zug war“; Wenn Sie seitdem andere Befehle ausgeführt haben, suchen Sie zuerst mit git reflog nach der richtigen Zahl.

Git Reflog erklärt: Das Sicherheitsnetz unter jedem Befehl

Das Reflog (Referenzprotokoll) ist ein privates Tagebuch darüber, worauf HEAD und Ihre Branchentipps hingewiesen haben. Bei jedem Commit, Checkout, Reset, Merge, Rebase, Amend und Pull wird eine Zeile hinzugefügt, und auch Remote-Tracking-Zweige wie origin/main erhalten eine. Es befindet sich nur in Ihrem lokalen .git-Ordner: Es wird nie gepusht und ein neuer Klon beginnt mit einem leeren.

git reflog
git reflog show main
git reflog --date=relative

Ein typischer git reflog nach einem Rebase sieht so aus, neuester Eintrag zuerst:

6c55495 HEAD@{0}: rebase (finish): returning to refs/heads/feature-login
6c55495 HEAD@{1}: rebase (pick): Validate the email field
cb6e15e HEAD@{2}: rebase (pick): Add the login form
2c44bc3 HEAD@{3}: rebase (start): checkout main
595b83d HEAD@{4}: commit: Validate the email field

Lesen Sie bis zur neuesten Zeile vor dem Fehler: hier HEAD@{4}, der vor rebase (start) durchgeführte Commit. Verwenden Sie seinen Hash oder diesen Namen überall dort, wo Git einen Commit erwartet; main@{2.hours.ago} funktioniert auch. Einträge verfallen nach 90 Tagen bzw. nach 30 Tagen für Commits, die kein Zweig erreichen kann, und solange ein Eintrag vorhanden ist, behält git gc seinen Commit bei.

Git macht den letzten Commit rückgängig: Soft-, Mixed- oder Hard-Reset

Wenn sich der Commit immer noch nur auf Ihrem Computer befindet, verschiebt git reset den Zweig um einen Commit nach hinten. Der Modus entscheidet, was mit seinen Änderungen passiert:

git reset --soft HEAD~1
git reset HEAD~1
git reset --hard HEAD~1

• --soft hält die Änderungen bereit und kann erneut festgeschrieben werden: ideal zum Korrigieren der Nachricht oder zum Hinzufügen einer vergessenen Datei.
• --mixed, die Standardeinstellung, behält die Änderungen in Ihrem Arbeitsordner, ohne Bereitstellung, sodass Sie den Commit aufteilen können.
• --hard verwirft die Änderungen zusammen mit dem Commit, zusammen mit allen nicht festgeschriebenen Änderungen. Das Reflog behält das Commit für eine Weile bei, aber denken Sie zweimal darüber nach.

Wenn Sie es bereits gepusht haben, schreiben Sie es nicht neu: git revert HEAD zeichnet einen neuen Commit auf, der ihn abbricht. Die kostenlose Lektion Fehler nach dem Drücken wiederherstellen behandelt das Zurücksetzen und die anderen sicheren Wege zurück.

Machen Sie git commit --amend rückgängig

Ein Amend ersetzt den Commit durch einen neuen; Das Original bleibt im Reflog. Unmittelbar nach der Änderung setzt git reset --soft HEAD@{1} den Zweig wieder auf das Original und belässt das, was durch die Änderung hinzugefügt wurde, im Staging. Suchen Sie später die Zeile commit (amend) in git reflog und verwenden Sie den Eintrag darunter.

git reset --soft HEAD@{1}

So machen Sie den Git-Reset --hard rückgängig

Ein Hard-Reset verschiebt den Zweig und überschreibt Ihre Dateien, aber die gelöschten Commits befinden sich immer noch in der Objektdatenbank von Git. Im Reflog wird die Verschiebung als reset: moving to HEAD~2 angezeigt, und die Zeile darunter zeigt an, wo Sie sich befanden. Wenn das Zurücksetzen Ihr letzter Befehl war, bringt dies alles zurück:

git reflog
git reset --hard HEAD@{1}

git fsck --lost-found

So machen Sie einen Git-Rebase rückgängig

Wenn das Rebase aufgrund eines Konflikts gestoppt wurde, gibt git rebase --abort den Zweig, den Index und Ihre Dateien an den Ort zurück, an dem sie sich befanden. Wenn es fertig ist, haben Sie zwei Möglichkeiten zurück. Git zeigt ORIG_HEAD auf den alten Tipp, wenn ein Rebase beginnt, also macht git reset --hard ORIG_HEAD es gleich danach rückgängig. Noch stabiler ist das eigene Reflog des Zweigs: Ein Rebase verschiebt den Zweig nur einmal, bei rebase (finish), sodass feature-login@{1} der Zweig genau so ist, wie er war. Wenn ein Rebase oder Cherry-Pick pausiert, wird in der Lektion Eine aktive Operation fortsetzen, überspringen oder abbrechen jeder Ausweg erläutert.

git rebase --abort
git reset --hard ORIG_HEAD
git reset --hard feature-login@{1}

Wenn Sie den neu erstellten Zweig gepusht haben, ist zum Wiederherstellen ein Force-Push erforderlich (siehe unten). Um den Verlauf absichtlich neu zu schreiben, lesen Sie unseren Leitfaden zu interaktivem Rebase in einer Git-GUI.

Machen Sie eine Git-Zusammenführung rückgängig

Bei einer Zusammenführung bleibt auch der alte Tipp in ORIG_HEAD, sodass git reset --hard ORIG_HEAD einen Tipp rückgängig macht, den Sie nicht verschoben haben. Mitten im Konflikt holt Sie git merge --abort heraus, oder folgen Sie unserem Leitfaden zum Lösen von Git-Merge-Konflikten. Eine gepushte Zusammenführung wird mit git revert -m 1 <merge-commit> rückgängig gemacht; Wenn Sie diesen Zweig später erneut zusammenführen, werden diese Änderungen nicht wiederhergestellt, es sei denn, Sie machen die Wiederherstellung rückgängig.

git merge --abort
git reset --hard ORIG_HEAD
git revert -m 1 <merge-commit>

Einen gelöschten Git-Zweig (und einen gelöschten Stash) wiederherstellen

Durch das Löschen eines Zweigs wird ein Name gelöscht, nicht die Commits. git branch -D gibt den Tipp aus, auf den der Zweig zeigte, und durch erneutes Erstellen des Zweigs aus diesem Hash wird er wiederhergestellt:

git branch feature-login 1a2b3c4
git reflog | grep "moving from feature-login"

Diese Ausgabe verloren? Der Reflog von HEAD erinnert sich noch. Der zweite Befehl findet checkout: moving from feature-login to main; Der um eine Nummer höhere Eintrag (HEAD@{6}, wenn die Übereinstimmung HEAD@{5} ist) ist der letzte Commit des Zweigs. Wenn sich der Zweig noch auf der Fernbedienung befindet, ist git branch feature-login origin/feature-login schneller. Um einen Commit anstelle des gesamten Zweigs wiederherzustellen, wenden Sie ihn mit Cherry-Pick an.

Stellen Sie einen verlorenen Vorrat wieder her

git stash drop und git stash pop geben den Hash des entfernten Stashs aus und git stash apply <hash> bringt ihn zurück. Ohne den Hash schlägt die Dokumentation von Git diese Suche nach nicht erreichbaren Stash-Commits vor; Es findet Stashes, die mit der Standardmeldung „WIP am …“ gespeichert wurden:

git stash apply 9d668e5
git fsck --unreachable | grep commit | cut -d' ' -f3 | xargs git log --merges --no-walk --grep=WIP --oneline

So machen Sie einen Force-Push rückgängig

Ein Force-Push ersetzt den Remote-Zweig durch Ihren, sodass Commits, die sich nur auf dem Remote-Zweig befanden, herausfallen. Auch Ihr Remote-Tracking-Zweig führt ein Reflog durch: origin/main@{1} ist dort, wo sich der Remote-Zweig vor Ihrem Push befand, so wie Sie ihn zuletzt gesehen haben, und die Push-Ausgabe gab denselben Hash aus wie die erste Hälfte von old...new.

git reflog show origin/main
git push --force-with-lease origin 1a2b3c4:main

--force-with-lease lehnt den Push ab, wenn sich die Fernbedienung seit Ihrem letzten Abruf bewegt hat, sodass Sie den Fix eines Teamkollegen nicht versehentlich überschreiben können. Commits, die Sie nie abgerufen haben, befanden sich nie auf Ihrem Computer; Wer sie gestoßen hat, kann sie noch einmal schieben. Dann erzählen Sie es jedem, der dazwischen gekommen ist. Das Video zur Wiederherstellung gepushter Fehler zeigt die gesamte Reparatur.

Mit einem Klick rückgängig machen in GitTree: ein Wiederherstellungs-Snapshot für 19 Arten von Vorgängen

Alles oben Genannte funktioniert auch in GitTree: Es führt Ihr installiertes Git (2.39 oder neuer) aus und sein integriertes Terminal öffnet Ihre eigene Shell unter dem Commit-Graph. Was es hinzufügt: GitTree speichert einen Wiederherstellungs-Snapshot unter refs/ogt/trash für 19 Arten von Vorgängen und speichert alles, was ein destruktiver Schritt entfernen würde, bevor er ausgeführt wird, und die Schaltfläche „Rückgängig“ in der Symbolleiste macht den letzten Schritt rückgängig.

Das Rückgängigmachen umfasst Festschreibungen und Änderungen, Auschecken, Zurücksetzen, Rebases (auch interaktive), verworfene Dateien, Teile und Zeilen, gelöschte Zweige und Tags, bereinigte nicht verfolgte Dateien und mehr. Bei einem Hard-Reset-Lauf von GitTree enthält der Snapshot auch Ihre nicht festgeschriebenen Änderungen, die einfach mit git reset --hard nicht wiederhergestellt werden können.

Zwei der 19 werden beibehalten und nicht umgekehrt. Ein Force-Push verändert eine Fernbedienung, die nur durch einen weiteren Push wieder zurückgeändert werden kann, also behält GitTree die Spitze, die es ersetzt hat, und überlässt diesen Push Ihnen (es erzwingt immer einen Force-Push mit --force-with-lease). Von einem gelöschten Stash wird ein Snapshot erstellt, aber durch „Rückgängig“ wird er noch nicht wiederhergestellt. GitTree lehnt auch ein Rückgängigmachen ab, das spätere Arbeiten überschreiben würde, und gibt den Grund dafür an. Ein normaler Push kann über die App nicht rückgängig gemacht werden; stattdessen zurücksetzen.

Gewohnheiten, die dafür sorgen, dass jeder Git-Fehler reversibel bleibt

• Frühes Commit, sogar chaotisch. Nur Commit-Arbeit erreicht das Reflog; Räumen Sie es später mit einem interaktiven Rebase auf.
• Verzweigung vor riskanten Änderungen. git branch backup/before-rebase kostet nichts und läuft nie ab.
• Verwenden Sie niemals ein einfaches `--force`. --force-with-lease überschreibt keine Commits, die Sie nicht gesehen haben.
• Geteilten Verlauf zurücksetzen, privaten Verlauf zurücksetzen. Sobald andere einen Commit durchgeführt haben, setzen Sie ihn zurück.
• Git auf dem neuesten Stand halten. GitTree benötigt Git 2.39 oder neuer und Ubuntu 22.04 wird mit Version 2.34 ausgeliefert; siehe So aktualisieren Sie Git unter Ubuntu.

Sie entscheiden sich immer noch zwischen Tippen und Klicken? Lesen Sie Git GUI vs. Befehlszeile oder beginnen Sie mit Git für Anfänger, mit einer GUI.

GitTree verfügt über einen kostenlosen Plan, der alle Git-Funktionen abdeckt, einschließlich privater Repositories, auf macOS 13 oder höher, Windows 10 und 11 (x64) und 64-Bit Linux (x86_64: Ubuntu 22.04+, Debian 12+), und Nour, der KI-Assistent, wird mit GitTree Pro geliefert (siehe Preise). Zur Anmeldung sind Git 2.39 oder neuer und ein GitTree-Konto erforderlich. Laden Sie es von der Download-Seite herunter oder sehen Sie, wie es unter Linux ausgeführt wird.