Einführung

Git bietet mehrere Möglichkeiten, etwas rückgängig zu machen, je nachdem, ob die Änderung in Ihrem Working Tree, im Index, in Ihrem letzten Commit oder bereits gepusht ist. Die richtige Wahl verhindert Unfälle.

Working-Tree-Bearbeitungen verwerfen

Sie haben eine Datei bearbeitet, wollen die Änderungen aber wegwerfen:

git restore file.txt              # modern
git checkout -- file.txt          # klassisches Äquivalent

git restore ohne --source verwendet den Index, sodass die Datei in ihren letzten git add-Zustand zurückkehrt.

Unstagen

Sie haben git add ausgeführt, wollen aber eine Datei aus dem nächsten Commit nehmen (ohne Bearbeitungen zu verlieren):

git restore --staged file.txt
git reset HEAD file.txt           # ältere Syntax

Den letzten Commit ändern

Sie haben committet, wollen aber die Nachricht korrigieren oder eine weitere Datei einbeziehen:

git commit --amend -m "Better message"
git add forgotten.txt
git commit --amend --no-edit

Ändern Sie nur Commits, die Sie noch nicht gepusht haben, oder seien Sie bereit für einen Force-Push.

Einen öffentlichen Commit revertieren

Wenn ein schlechter Commit bereits gepusht ist, schreiben Sie die Historie nicht um. Erstellen Sie einen neuen Commit, der ihn rückgängig macht:

git revert <sha>
git push

git revert öffnet einen Editor mit einer generierten Nachricht; das Ergebnis ist ein sauberes Undo, das jeder pullen kann.

Resetten

git reset bewegt den Zeiger des aktuellen Branches. Es hat drei Modi:

• --soft: nur den Branch verschieben; Index und Working Tree behalten.
• --mixed (Standard): Branch verschieben und Index zurücksetzen; Working Tree behalten.
• --hard: Branch verschieben, Index zurücksetzen, Working Tree zurücksetzen. Destruktiv.

git reset --soft HEAD~1            # Uncommit, Änderungen bleiben gestaged
git reset HEAD~1                   # Uncommit, Änderungen bleiben unstaged
git reset --hard HEAD~1            # letzten Commit und Änderungen vernichten

Wiederherstellung nach --hard

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

Das Reflog erinnert sich 90 Tage an jede Bewegung von HEAD.

Das richtige Undo wählen

Eine einfache Entscheidungsmatrix:

• Nur Working Tree: git restore <file>
• Gestagte Datei: git restore --staged <file>
• Letzter ungepushter Commit: git commit --amend oder git reset --soft HEAD~1
• Gepushter Commit: git revert <sha>
• Ganze Branch-Spitze: git reset --hard ORIG_HEAD (nach einem schlechten Merge/Rebase)

git status
git diff
git log --oneline -5

Führen Sie diese drei immer vor jedem destruktiven Undo aus. Sie zeigen Working Tree, gestagte Änderungen und jüngste Historie; zusammen sagen sie Ihnen, welches Undo sicher ist.

Häufige Fehler

revert mit reset verwechseln. Revert fügt hinzu; Reset entfernt. git reset --hard mit uncommitted Arbeit ausführen und dann merken, dass Sie sie brauchten; greifen Sie sofort zum Reflog, bevor Garbage Collection läuft. Einen gepushten Commit ändern und den Force-Push nicht mit Teamkollegen abstimmen. Verwenden Sie git revert auf geteilter Historie. Und schließlich: git checkout file als sicher behandeln; in älterem Git überschreibt es ohne Papierkorb stillschweigend Ihre Bearbeitungen. Modernes git restore ist nicht anders; sichern Sie zuerst, falls unsicher.