Es gibt nicht nur einen Weg, Arbeit in Git rückgängig zu machen, und git reset revert mit git stash zu verwechseln gehört zu den häufigsten Stolperfallen. Alle drei fühlen sich wie "rückgängig" an, tun aber sehr Unterschiedliches: das eine legt Änderungen für später beiseite, das eine spult die Historie zurück, und das eine erzeugt einen neuen Commit, der eine Änderung rückgängig macht, ohne die Vergangenheit anzutasten. Zu wissen, wozu man greift, ist der Unterschied zwischen einem verlorenen Arbeitsabend und einer sauberen Historie.
Drei Befehle, drei verschiedene Ziele
Klären wir zuerst das mentale Modell. Git hat drei Bereiche: das Arbeitsverzeichnis (Working Directory), die Staging-Area (Index) und die Commit-Historie (HEAD). Diese Befehle unterscheiden sich darin, welchen dieser Bereiche sie anfassen.
git stash— legt nicht committete Änderungen aus Arbeitsverzeichnis und Index beiseite und bringt den Baum auf den letzten Commit zurück. Nichts wird zerstört; du kannst es später zurückholen.git reset— verschiebt HEAD (und wahlweise Index und Arbeitsverzeichnis) auf einen anderen Commit. Es schreibt die Historie um.git revert— erzeugt einen neuen Commit, der die Wirkung eines früheren rückgängig macht. Die Historie bleibt intakt, mit einem "Rückgängig" obendrauf.
git stash: laufende Arbeit sicher parken
Du steckst mitten in einem Feature, als du plötzlich den Branch wechseln und einen dringenden Fix ausliefern musst, aber deine aktuelle Arbeit ist noch nicht commit-reif. Genau dafür ist git stash da.
git stash push -m "halbfertiges Filterformular"
# der Baum ist jetzt sauber, Branch wechseln, Hotfix machen...
git stash list
git stash pop # den letzten Stash wiederherstellen und aus der Liste entfernen
git stash apply # wiederherstellen, aber in der Liste behaltenMit git stash -u nimmst du auch nicht getrackte Dateien mit. Bei mehreren Stashes kannst du einen per Index ansprechen, etwa git stash pop stash@{1}. Ein Stash ist wie eine vorübergehende Tasche: Du legst Arbeit beiseite, ohne zu committen oder den Branch zu verunreinigen. Es ist allerdings kein Langzeitspeicher — statt Arbeit tagelang im Stash zu lassen, ist ein WIP-Commit sicherer.
git reset: HEAD zurückspulen
git reset ist der mächtigste und am meisten missverstandene Befehl. Seine drei Modi sind drei Härtegrade:
--soft— verschiebt nur HEAD. Deine Änderungen bleiben im Index, als hättest du geradegit addausgeführt. Ideal, um die letzten Commits zu einem zusammenzufassen.--mixed(Standard) — verschiebt HEAD und setzt den Index zurück. Die Änderungen bleiben "ungestaged" im Arbeitsverzeichnis.--hard— setzt HEAD, Index und Arbeitsverzeichnis auf einmal zurück. Alles nicht Committete ist weg.
# Die letzten 3 Commits zu einem zusammenfassen (ohne die Änderungen zu verlieren)
git reset --soft HEAD~3
git commit -m "Filterfunktion"
# Eine versehentlich gestagte Datei aus dem Index nehmen (Inhalt bleibt)
git reset HEAD datei.php
# ACHTUNG: den Arbeitsbaum zwangsweise auf den letzten Commit zurücksetzen
git reset --hard HEADDie goldene Regel: Verwende git reset nur bei Commits, die du noch nicht geteilt (gepusht) hast. Wenn du Commits mit reset auf einem geteilten Branch entfernst und mit --force pushst, weicht die Historie aller anderen von deiner ab.
git revert: geteilte Historie sicher rückgängig machen
Wenn ein fehlerhafter Commit bereits auf main gelandet ist und andere ihn gepullt haben, kannst du die Historie nicht löschen. git revert ist hier das richtige Werkzeug: Es fügt einen neuen Commit hinzu, der alles rückgängig macht, was der fehlerhafte Commit getan hat.
# Einen bestimmten Commit rückgängig machen
git revert a1b2c3d
# Einen Merge-Commit rückgängig machen — gib an, welche Hauptlinie bleibt
git revert -m 1 <merge-sha>
# Die gegenteilige Änderung anwenden, ohne einen Commit zu erstellen
git revert --no-commit a1b2c3dRevert bricht die Historie nicht, was es zur sichersten Wahl bei Teamarbeit und auf Produktionsbranches macht. Statt die Zeitleiste für einen Fehler umzuschreiben, den alle sehen können, hinterlässt du einen ehrlichen Eintrag, der sagt: "Ich habe diesen Commit rückgängig gemacht."
Welcher wann?
- Halbfertige Arbeit beiseitelegen, um den Branch zu wechseln → stash
- Noch nicht gepushte Commits zusammenfassen oder aufräumen → reset --soft oder
git commit --amend - Eine falsch gestagte Datei aus dem Index nehmen → reset (mixed)
- Lokal alles auf den letzten Commit zurücksetzen → reset --hard (Vorsicht)
- Einen geteilten/gepushten Commit rückgängig machen → revert
Wenn du versehentlich gelöscht hast: das Reflog rettet dich
Commits, die du durch git reset --hard verloren glaubst, sind meist noch da. Git zeichnet jede Bewegung von HEAD im reflog auf:
git reflog
# finde die sha des Ziel-Commits in der Ausgabe, dann:
git reset --hard a1b2c3d
# oder hole den verlorenen Commit in einen neuen Branch
git branch rettung a1b2c3dReflog-Einträge bleiben standardmäßig 90 Tage erhalten, also schau vor jeder Panik immer zuerst ins Reflog.
Häufige Fragen
Kann ich mit git reset --hard verlorene Dateien wiederherstellen?
Wenn die verlorene Änderung vorher committet wurde, ja: Finde den Commit mit git reflog und kehre dorthin zurück. Aber Änderungen, die nie committet wurden und nur im Arbeitsverzeichnis lagen, entfernt --hard endgültig; die kann das Reflog nicht retten.
Kann ich nach einem Push einen Reset machen?
Technisch ja, mit --force, aber tu es nicht auf geteilten Branches. Wenn andere diese Commits gepullt haben, gabelt sich die Historie. Verwende stattdessen git revert; das liefert das gleiche Ergebnis ohne Risiko.
Was ist der Kernunterschied zwischen stash und reset?
Stash dient dazu, Änderungen zu sichern und später zurückzugeben, ohne die Historie anzutasten. Reset verschiebt HEAD und Index tatsächlich. Parkst du Arbeit, "um später weiterzumachen", denk an stash; bearbeitest du die Historie, denk an reset.
Klären wir deine Rückgängig-Strategie. Willst du ein solides Setup für deinen Git-Flow, dein Release-Management oder deine CI/CD-Pipeline? Nimm Kontakt auf und wir bauen gemeinsam den sichersten Workflow für dein Projekt.