git reset --soft HEAD~1 entfernt den Commit und lässt alle Änderungen im Index, genau wie einen Moment vor dem Commit. Das ist die Antwort für den üblichen Fall. Wichtiger als die Option ist, in welchem Fall du dich befindest.
1. Noch nicht gepusht — Commit rückgängig machen, Arbeit im Index behalten
$ clai mach meinen letzten Commit rückgängig, aber behalte die Änderungen im Index→ git reset --soft HEAD~1$ git status --shortM f.txtDer Commit ist aus dem Log verschwunden, die Dateien sind unangetastet, alles ist noch im Index. Korrigiere die Nachricht oder füge die vergessene Datei hinzu und committe erneut.
2. Änderungen behalten, aber aus dem Index nehmen
$ clai mach den letzten Commit rückgängig und nimm die Änderungen auch aus dem Index→ git reset HEAD~1--mixed ist die Standardeinstellung. Wie soft, nur einen Schritt weiter: Die Dateien bleiben auf der Festplatte, der Index wird geleert. Nutze es, wenn du die Arbeit auf andere Commits aufteilen willst.
3. Die Arbeit komplett verwerfen
$ clai lösche meinen letzten Commit und alle seine Änderungen dauerhaft→ git reset --hard HEAD~1⚠ DANGER — uncommitted changes in the working tree are destroyed--hard ist der einzige der drei, der Arbeit verliert. Committeter Inhalt lässt sich über reflog wiederherstellen; was du geändert, aber nicht committet hattest, nicht.
4. Schon gepusht — revert statt reset
$ clai mach den Commit rückgängig, den ich schon gepusht habe, ohne die Historie umzuschreiben→ git revert HEADrevert erstellt einen Commit, der neu ist und den alten rückgängig macht. Die Historie bleibt intakt, niemand, der schon gepullt hat, muss etwas tun. Auf einem gemeinsamen Branch ist das die einzig richtige Antwort.
5. Nur die Nachricht korrigieren
$ clai ändere die Nachricht meines letzten Commits→ git commit --amend -m "Fix cache invalidation on write path"Ist nichts im Index, schreibt --amend nur die Nachricht neu. Ist etwas im Index, fließt das zusätzlich in den vorherigen Commit ein — nützlich, aber leicht versehentlich ausgelöst.
6. Falsch entschieden — zurückholen
$ clai zeig mir, wo HEAD vor diesem Reset stand→ git reflog4d2e830 HEAD@{0}: reset: moving to HEAD~1dc4fa62 HEAD@{1}: commit: second4d2e830 HEAD@{2}: commit (initial): first$ git reset --hard dc4fa62reflog merkt sich standardmäßig jede Position, die HEAD 90 Tage lang hatte. Ein --hard-Reset auf einen verlorenen Commit bringt ihn exakt so zurück, wie er war.
Fallstricke
- Push einen Reset niemals mit Force auf einen gemeinsamen Branch. Eine umgeschriebene Historie, die andere schon gepullt haben, zerstört deren Klone. Genau dafür gibt es
revert. HEAD~1undHEAD^sind hier dasselbe — ein Commit zurück. Sie unterscheiden sich nur bei Merge-Commits, woHEAD^2den zweiten Elternteil meint.--amendnach dem Push schreibt ebenfalls die Historie um. Es erzeugt ein neues Commit-Objekt mit neuem Hash, also gilt dieselbe Regel.
Verwandte Fragen
Wie mache ich die letzten drei Commits rückgängig und behalte alle Änderungen? git reset --soft HEAD~3 — alles aus diesen Commits landet zusammen im Index.
Löscht reset den Commit dauerhaft? Nicht sofort. Er wird unerreichbar, und reflog zeigt standardmäßig noch etwa 90 Tage darauf, bis die Garbage Collection läuft.
Reset oder revert auf einem Feature-Branch, den sonst niemand nutzt? Reset. Es ist sauberer. Revert, sobald jemand anderes ihn gepullt haben könnte.
Siehe auch
- Git-Aufgaben, laut ausgesprochen: „zeig mir Commits, die ich nicht gepusht habe"
- SAFE, CAUTION, DANGER: wie CliAI einstuft, was gerade ausgeführt wird
- Tag 1 im Onboarding: wie CliAI das „frag den Senior in Slack" ersetzt
CliAI kennzeichnet reset --hard als DANGER und verlangt eine getippte Bestätigung — der einzige Git-Befehl, der wirklich Arbeit vernichtet. In einer Zeile installieren.