Git: Letzten Commit rückgängig machen — Änderungen behalten

TL;DR: Um den letzten Commit rückgängig zu machen und die Änderungen zu behalten, führe git reset --soft HEAD~1 aus (Änderungen bleiben gestaged) oder git reset HEAD~1 (Änderungen bleiben im Working Tree). Ist der Commit schon gepusht, nimm stattdessen git revert HEAD — es erzeugt einen neuen Commit, der ihn ausgleicht, ohne History umzuschreiben. Diese drei Befehle decken fast jeden Moment „zu früh committet” ab. Der Rest dieses Guides geht jeden Fall mit Copy-Paste-Befehlen durch, erklärt den Unterschied zwischen --soft, --mixed und --hard und zeigt, wie du wiederherstellst, wenn etwas schiefgeht. Jeder Befehl unten läuft auf jeder aktuellen Git-Installation unter Linux, macOS oder Windows.

Wie mache ich den letzten Commit rückgängig und behalte die Änderungen?

Die häufigste Situation: Du hast committet, dann einen Tippfehler oder eine fehlende Datei entdeckt — oder realisiert, dass die Änderung in einen anderen Commit gehört. Nichts ist gepusht. Mach den Commit rückgängig und leg alles zurück, wo es war:

# Der Commit ist danach nirgends in der History — die Änderungen landen zurück in der Staging Area
git reset --soft HEAD~1

# Die Änderungen landen stattdessen zurück im Working Tree (ungestaged)
git reset HEAD~1

HEAD~1 bedeutet „ein Commit vor dem Punkt, auf den HEAD gerade zeigt”. Nach beiden Befehlen sind deine Dateien auf der Platte unangetastet — nur der Branch-Pointer hat sich bewegt. Prüfe es mit git status: Mit --soft sind die Änderungen gestaged, bereit zum erneuten Committen inklusive Fixes; ohne Flag sind sie ungestaged, du kannst also erst frei bearbeiten.

Eine sicherere Gewohnheit, wenn du nur Dateien zum letzten Commit hinzufügen willst: ihn gar nicht rückgängig machen.

git add forgotten-file.txt
git commit --amend --no-edit

--amend ersetzt den letzten Commit an Ort und Stelle (hier ohne Änderung der Commit-Message). Beachte: Ein Amend an einem gepushten Commit schreibt History um — dazu unten mehr.

Was ist der Unterschied zwischen —soft, —mixed und —hard?

Das ist der Teil, den man auswendig kennen sollte, denn das Flag entscheidet, wo deine Änderungen landen — und ob sie verloren gehen können:

Flag	Commit aufgehoben?	Änderungen auf der Platte	Änderungen gestaged?	Typischer Einsatz
--soft	Ja	Behalten	Ja	Erneut committen mit kleinen Fixes
--mixed (Standard)	Ja	Behalten	Nein	Änderungen neu gruppieren, selektiv stagen
--hard	Ja	Gelöscht	—	Die Arbeit komplett wegwerfen
git revert	Nein (neuer Commit)	Behalten	—	Einen bereits gepushten Commit ausgleichen

--hard ist das einzige gefährliche Flag: Es verwirft den Commit und die Änderungen. Vor jedem reset --hard — Stash oder Branch, was du hast:

git branch backup-before-reset   # billige Versicherung
git reset --hard HEAD~1          # Commit + Änderungen weg

Wenn du die gefährliche Variante schon gelaufen bist, ist alles nicht verloren — git reflog weiß noch, wo HEAD war:

git reflog                       # den Hash des verlorenen Commits finden
git reset --hard HEAD@{1}        # oder: git reset --hard <hash>

Der Reflog hält verwaiste Commits standardmäßig rund 90 Tage lang — „ich habe versehentlich einen Hard-Reset gefahren” ist daher fast immer wiederherstellbar, wenn du vor der Garbage Collection handelst.

Was, wenn ich den Commit schon gepusht habe?

Liegt der Commit auf einem gemeinsamen Branch (alles außer deinem eigenen Feature-Branch), schreib nicht die History um. Nimm git revert — es berechnet die gegenteilige Änderung und committet sie:

git revert HEAD
git push

Alle, die pullen, bekommen einfach einen neuen Commit, der die Änderungen des alten entfernt. Kein Force-Push, keine zerbrochenen Kollegen. Musst du eine Reihe von Commits ausgleichen, revert die Range: git revert --no-commit HEAD~3..HEAD && git commit.

Die Alternative — git reset --hard HEAD~1 && git push --force-with-lease — ist nur auf einem Branch akzeptabel, auf dem niemand sonst aufbaut, und --force-with-lease (nie das nackte --force) ist die einzige sichere Form, weil es sich weigert, wenn zwischendrin jemand gepusht hat. Force-Pushes auf gemeinsame Branches sind der Grund, warum Teams Commits verlieren und CI-Logs plötzlich zu niemandes Checkout mehr passen.

Wie hebe ich den letzten Commit auf, ohne ihn wegzuwerfen?

Manchmal ist der Commit gute Arbeit an der falschen Adresse — auf dem falschen Branch oder zu früh. Statt ihn rückgängig zu machen, verschieb ihn:

git branch stash-commit          # den Commit auf einem neuen Branch parken
git reset --hard HEAD~1          # dann den aktuellen Branch aufräumen

Oder nimm nur den Commit mit auf einen anderen Branch, ohne deinen aktuellen anzufassen:

git cherry-pick <hash>           # während du auf dem Ziel-Branch bist

Zwischen reset --soft, cherry-pick und revert gibt es keinen Commit, den du nicht verschieben oder neutralisieren kannst — die Kunst liegt darin, vor dem Greifen nach einem Flag zwischen „verschieben” und „rückgängig” zu wählen.

Welches Undo nehme ich? Ein schneller Entscheidungsguide

1. Nicht gepusht, fixen und neu committen → git reset --soft HEAD~1
2. Nicht gepusht, selektiv neu stagen → git reset HEAD~1 (mixed)
3. Die Änderungen sollen komplett weg → git reset --hard HEAD~1 (der Reflog weiß es, falls du es bereust)
4. Schon auf einen gemeinsamen Branch gepusht → git revert HEAD
5. Der Commit gehört auf einen anderen Branch → cherry-pick, nicht rückgängig machen

Ein letzter Betriebstipp: Wenn ein schlechter Commit es bis auf einen Server geschafft hat — ein schiefgelaufener Deploy-Hook, ein CI-Runner, der sich nach einem Force-Push seltsam verhält — ist die nächste Anlaufstelle das Log der Maschine, nicht Git. Auf jedem systemd-Kasten zeigt dir journalctl -u <service> -n 100 exakt, was wann lief; unser journalctl-Spickzettel hat die Copy-Paste-Patterns. Und wenn zu deinem Workflow lokale LLM-Tools fürs Diff-Review gehören: Die beiden Hauptoptionen vergleichen wir in Ollama vs LM Studio.