# Änderungen in Claude Code rückgängig machen: /rewind und git > Rewind-Modi, Einschränkungen von Checkpoints, git checkout, stash, reflog und Schutz vor destruktiven Befehlen. Fünf Möglichkeiten, einen Zustand wiederherzustellen. Source: https://ailoot.ai/blog/de/claude-code-undo-changes/ Canonical: https://ailoot.ai/blog/de/claude-code-undo-changes/ Language: de Publisher: Ailoot (https://ailoot.ai/) Translation: guide-138 Revision: sha256-c2bfa19e6afe9117ce24510050f5fc149161ef692d05114ce6c4cf14ba443e7d [Praktische Informationen zur Arbeit mit Ailoot findest du in der Dokumentation](https://ailoot.ai/docs/). ## Was bedeutet Rückgängig in Claude Code, und warum reichen drei Ebenen nicht aus?
Das Wichtigste Rückgängig machen in Claude Code hat drei Ebenen: den integrierten Befehl `/rewind` (sofortige Wiederherstellung innerhalb einer Sitzung), `git checkout` (Rückkehr zum letzten Commit) und `git reflog` (Sicherheitsnetz für den Katastrophenfall, falls jemand `git reset --hard` ausgeführt hat). Jede Ebene deckt ihre eigene Fehlerklasse ab und nichts darüber hinaus. Nur `/rewind` zu kennen bedeutet, beim ersten ernsthaften Fehler völlig aufgeschmissen zu sein.
Ich habe `/rewind` in meiner ersten Woche mit Claude Code aktiviert, als es die Authentifizierungslogik meines Projekts in zwei Prompts kaputtmachte. Ich setzte zurück, atmete aus und arbeitete weiter. Einen Monat später kam es zu einer anderen Situation: Ich schrieb eine Schema-Migration, Claude half mir, ich committete, wechselte den Branch – und stellte fest, dass ich einen notwendigen Schritt vergessen hatte. `/rewind` half nicht – die Sitzung war bereits eine andere. `git checkout` zum vorherigen Commit half. Einen Monat danach sagte ich dem Agenten versehentlich: „Setz alles auf den letzten Push zurück“, und er führte `git reset --hard` aus, wodurch drei Stunden Arbeit zerstört wurden. `git reflog` rettete mich – die Hashes der zerstörten Commits waren noch da. Diese drei Geschichten zeigen drei Schutzebenen, die unterschiedlich funktionieren, verschiedene Fehler auffangen und alle nötig sind. Dieser Leitfaden erklärt jede Ebene mit ihren Befehlen, Einschränkungen und Beispielen. Außerdem zeigt er, wie du ein Projekt im Voraus einrichtest, damit Claude es nicht gleich beim ersten Mal lahmlegt. **3 Ebenen des Rückgängigmachens – was und wann:** | Ebene | Befehl | Deckt ab | Deckt NICHT ab | |----|----|----|----| | 1\. Innerhalb einer Sitzung | `/rewind` oder `Esc Esc` | Dateien, die Claude mit seinen eigenen Werkzeugen geändert hat; Gesprächsverlauf | Bash-Befehle, externe Editoren, Datenbankmigrationen | | 2\. Vor einem Commit | `git checkout .` oder `git stash` | Alle nicht committeten Dateiänderungen | Committete Commits | | 3\. Katastrophe | `git reflog` + `git reset --hard ` | Durch `reset --hard` oder Force-Push zerstörte Commits | Destruktive Bash-Befehle (rm, Datenbankmigrationen) | Als Nächstes gehen wir jede Ebene durch – was genau zu tun ist, welche Fallstricke es gibt und wie du alles so einrichtest, dass nichts rückgängig gemacht werden muss, weil nichts kaputtgegangen ist. ## Wie rufst du /rewind auf: mit dem Befehl oder Esc-Esc?
Das Wichtigste Es gibt zwei Möglichkeiten, das Rewind-Menü in Claude Code zu öffnen. Erstens kannst du `/rewind` in das Eingabefeld eingeben. Zweitens kannst du zweimal `Esc` drücken, wenn das Eingabefeld leer ist. Steht Text im Feld, löscht doppeltes Esc ihn zunächst und speichert seinen Inhalt im Eingabeverlauf; ein weiteres doppeltes Drücken öffnet das Menü. Der Befehl `/rewind` ist ein Alias für `/checkpoint`.
Nach jeder Antwort erstellt Claude automatisch einen Snapshot aller Dateien, die es in dieser Sitzung bearbeitet hat. Die Snapshots werden in `~/.claude/file-history/{sessionId}/` gespeichert und bis zu 30 Tage aufbewahrt. Sie sind inkrementell – gespeichert werden nur die Unterschiede zwischen den Zuständen, nicht die vollständige Datei. Standardmäßig werden bis zu 100 Snapshots pro Sitzung gespeichert. Das bedeutet, dass du in den meisten realen Projekten jederzeit einen vollständigen Verlauf aller Änderungen von Claude während des Arbeitstags hast. Um das Rewind-Menü zu öffnen, drücke zweimal `Esc`, wenn das Eingabefeld leer ist: ``` [user-input is empty] > _ [press Esc, Esc] Rewind to which message? 1. Create a migration for the User table (3 files changed) 2. Add the lastLoginAt field (1 file changed) 3. Rewrite the authorization logic (5 files changed) ... ``` Wenn Text im Eingabefeld steht, löscht das erste doppelte Drücken von `Esc` ihn und speichert ihn im Verlauf, den du mit `Up` aufrufst. Das ist nützlich, wenn du schon mit dem Tippen begonnen hast und dann merkst, dass du zurücksetzen musst. Ein Zitat aus der offiziellen Dokumentation von Anthropic:

„Wenn der Prompt eine Texteingabe enthält, löscht doppeltes Esc zunächst den Text, anstatt das Menü zu öffnen. Der gelöschte Text wird im Eingabeverlauf gespeichert, sodass du ihn nach dem Rewind-Menü mit der Pfeiltaste nach oben wiederherstellen kannst.“

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Der Befehl `/rewind` macht dasselbe – er öffnet das Menü. Es gibt den Alias `/checkpoint`, der zum selben Menü führt. Welche Methode bequemer ist, ist Gewohnheitssache. Ich verwende `Esc Esc` – das geht schneller und ich muss die Hände nicht von der Tastatur nehmen. ## 6 Modi im Rewind-Menü: Welchen solltest du wann wählen?
Das Wichtigste Nachdem du im Rewind-Menü einen Zurücksetzpunkt ausgewählt hast, erscheint ein zweites Menü mit sechs Modi. Drei stellen einen Zustand wieder her (`Restore code and conversation`, `Restore conversation`, `Restore code`), zwei komprimieren den Verlauf (`Summarize from here`, `Summarize up to here`) und einer bricht die Aktion ab (`Never mind`). Das häufigste Szenario – „Code und Unterhaltung zurücksetzen“ – ist die erste Option.
Wähle einen Punkt in der Liste aus, dann gelangst du zum Aktionsmenü. Sechs Einträge, jeder mit einer anderen Funktion. **Vollständige Tabelle der Modi:** | Modus | Funktion | Wann du ihn wählen solltest | |----|----|----| | `Restore code and conversation` | Stellt sowohl Dateien als auch Gesprächsverlauf auf den ausgewählten Punkt zurück | Das häufigste Szenario: Claude ist in die falsche Richtung gegangen, und ich möchte mit der richtigen Formulierung neu beginnen | | `Restore conversation` | Setzt nur den Gesprächsverlauf zurück; die Dateien bleiben unverändert | Der Code ist gut, aber das Gespräch ist vom Weg abgekommen; ich formuliere ab diesem Punkt neu und behalte die aktuellen Änderungen bei | | `Restore code` | Setzt Dateien zurück; das Gespräch bleibt unverändert | Einige Änderungen von Claude waren unnötig, aber ich brauche den Gesprächskontext noch (zum Beispiel, weil wir die nächsten Schritte vereinbart haben) | | `Summarize from here` | Komprimiert alles NACH dem ausgewählten Punkt zu einer Zusammenfassung. Ändert keine Dateien | Eine lange Debugging-Sitzung hat den Kontext aufgebraucht; ich muss Platz schaffen und die ursprünglichen Anweisungen vollständig beibehalten | | `Summarize up to here` | Komprimiert alles VOR dem ausgewählten Punkt zu einer Zusammenfassung. Ändert keine Dateien | Auf eine lange erste Einweisung folgte eine konkrete Aufgabe – wir komprimieren die Einweisung zu einer Nachricht und lassen die jüngste Arbeit unverändert | | `Never mind` | Schließt das Menü, ohne Änderungen vorzunehmen | Ich habe es mir anders überlegt | Die Funktion `Summarize up to here` wurde in Claude Code v2.1.139-v2.1.142 eingeführt, veröffentlicht vom 11.–15. Mai 2026, in Woche 20:

„Du kannst frühen Kontext über das Rewind-Menü mit ‚Summarize up to here‘ komprimieren.“

— Anthropic What's new, https://code.claude.com/docs/en/whats-new
Der Unterschied zwischen `Restore` und `Summarize` ist grundlegend. Restore kehrt zu einem vorherigen Zustand zurück und macht alles rückgängig, was nach dem ausgewählten Punkt geschehen ist. Summarize macht nichts rückgängig, sondern komprimiert nur: Die ursprünglichen Nachrichten bleiben zur Referenz im Sitzungstranskript erhalten, aber im aktiven Kontext bleibt nur die Zusammenfassung. Verwende Restore, wenn es „so sein soll, als wäre das nie passiert“. Verwende Summarize, wenn du es „behalten, aber keinen Kontextplatz dafür verbrauchen“ möchtest. Nach `Restore conversation` oder `Summarize from here` erscheint der ursprüngliche Text des ausgewählten Prompts wieder im Eingabefeld – du kannst ihn bearbeiten und erneut senden. Nach `Summarize up to here` ist das Eingabefeld leer, und du bleibst am Ende der Unterhaltung. ## Welche Änderungen macht /rewind NICHT rückgängig?
Das Wichtigste `/rewind` erfasst nur Änderungen, die Claude mit seinen eigenen Werkzeugen zur Dateibearbeitung vorgenommen hat. Es kann nichts anderes erkennen oder wiederherstellen. Es gibt drei Arten unsichtbarer Änderungen: Bash-Befehle (rm, mv, cp), externe Bearbeitungen (manuelle Änderungen in einer IDE, Änderungen aus anderen Sitzungen) und Vorgänge außerhalb von Dateien (Datenbankmigrationen, git push, Remote-API-Aufrufe).
Auf diese Haupteinschränkung stoßen viele: `/rewind` zeigt ein grünes Häkchen und meldet „rewind successful“, aber das Projekt ist immer noch kaputt, weil Claude mehr als nur Dateien angefasst hat. Sehen wir uns die drei Fälle an. **1. Bash-Befehle werden nicht erfasst.** Wenn Claude in einem Zug `rm file.txt` oder `mv old.txt new.txt` ausführt, werden diese Änderungen nicht in den Checkpoint aufgenommen. Die Dokumentation von Anthropic stellt ausdrücklich fest:

„Checkpointing erfasst keine Dateien, die über Bash-Befehle geändert wurden. Wenn Claude Code zum Beispiel rm file.txt, mv old.txt new.txt oder cp source.txt dest.txt ausführt, können diese Dateiänderungen nicht über Rewind rückgängig gemacht werden.“

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Das bedeutet: Wenn Claude selbst mit dem Bash-Werkzeug eine Datei löscht, verschiebt oder kopiert, stellt `/rewind` nicht alles wieder her. `git checkout` oder eine Wiederherstellung aus einem Backup kann helfen, erfordert aber mehr als das Drücken zweier Tasten. **2. Externe Bearbeitungen werden nicht erfasst.** Wenn du eine Datei manuell in VS Code öffnest und bearbeitest oder eine zweite Claude-Sitzung dieselben Dateien parallel ändert, kann die erste Sitzung diese Änderungen nicht sehen. Ein Snapshot des Checkpoints wird erstellt, wenn Claude einen Zug in der aktuellen Sitzung beendet. Was zwischen den Zügen geschieht, liegt außerhalb seiner Verantwortung. **3. Vorgänge außerhalb von Dateien werden überhaupt nicht abgedeckt.** Eine mit `npx prisma migrate dev` angewendete Prisma-Migration hat das Datenbankschema geändert – `/rewind` macht das nicht rückgängig, weil sich die Datenbank außerhalb des Dateisystems des Projekts befindet. Ein Force-Push zu `origin/main` ist dasselbe: Der Commit ist auf den Remote-Server gelangt, und der Checkpoint kann ihn nicht zurückholen. Ein Remote-API-Aufruf, der Geld abgebucht oder einen Datensatz gelöscht hat, lässt sich nur mit den eigenen Mechanismen der API rückgängig machen. **Regel:** Wenn eine Aufgabe etwas außerhalb der Projektdateien betrifft – Datenbankmigrationen, git push, Remote-APIs –, bereite für jede externe Auswirkung eine eigene Rollback-Strategie vor. `/rewind` erfasst nur den lokalen Dateiverlauf innerhalb der aktuellen Sitzung. ## /rewind vs. git: Worin unterscheiden sie sich, und warum brauchst du beide?
Das Wichtigste `/rewind` ist ein lokaler Rollback innerhalb einer einzelnen Claude-Code-Sitzung. Es speichert inkrementelle Snapshots bis zu 30 Tage lang, bis zu 100 pro Sitzung. git ist der langfristige Projektverlauf, der mit dem Team geteilt wird und Branches, Merge-Konflikte und ein Remote-Repository umfasst. Das eine ersetzt das andere nicht. Bewährt hat sich, bei jedem logischen Meilenstein einen `git commit` zu erstellen und sich zwischen Commits auf `/rewind` zu verlassen.
Die Dokumentation von Anthropic beschreibt diese Kombination ausdrücklich:

„Checkpoints sind für die schnelle Wiederherstellung auf Sitzungsebene gedacht. Für Commits, Branches und den langfristigen Verlauf solltest du weiterhin ein Versionskontrollsystem (zum Beispiel Git) verwenden. Checkpoints ergänzen die normale Versionskontrolle, ersetzen sie aber nicht. Betrachte Checkpoints als ‚lokales Undo‘ und Git als ‚dauerhaften Verlauf‘.“

— Anthropic Docs, https://code.claude.com/docs/en/checkpointing
Die Unterschiede in einer Tabelle: | Parameter | /rewind | git | |----|----|----| | Granularität | Jeder Zug im Gespräch | Jeder Commit | | Speicherung | Bis zu 30 Tage, bis zu 100 pro Sitzung, lokal in `~/.claude/file-history/` | Dauerhaft im `.git/` des Repositorys und auf dem Remote-Server | | Was erfasst wird | Änderungen von Claude mit seinen eigenen Werkzeugen | Alle committeten Änderungen | | Was NICHT erfasst wird | Bash, externe Bearbeitungen, Migrationen, Push | Nicht committete Änderungen | | Befehl | Ein Befehl innerhalb von Claude | Ein externes Versionskontrollsystem | | Setzt das Gespräch zurück | Ja | Nein | | Funktioniert über Sitzungen hinweg | Nur innerhalb derselben Sitzung | Überall | Die Kombination ist einfach: Sobald du einen Zustand erreichst, bei dem „das funktioniert, und ich möchte es nicht verlieren“, erstelle einen `git commit`. Zwischen Commits verlässt du dich auf `/rewind` – es geht sofort, erfordert keine Commit-Nachricht und bläht den git-Verlauf nicht mit Zwischenständen auf. Wenn die Arbeit abgeschlossen ist, committe sie – am besten mit einem aussagekräftigen, atomaren Commit. ## Warum deckt ein einziges /rewind nicht die ganze Aufgabe ab? Rückgängig machen ist ein Anwendungsfall von **Context Engineering**. Wenn du den Sitzungskontext verwaltest (wann du committen, wann du `/rewind` drücken und welche Regeln du in `CLAUDE.md` festhalten solltest), erhältst du ein berechenbares Claude, das das Projekt nicht zerstört oder Arbeit verliert. ## Warum ist `git reset --hard` gefährlich, wenn du Claude bittest, „zurückzukehren“?
Das Wichtigste „Zurückkehren“ bedeutet in natürlicher Sprache „den Verlauf ansehen“, nicht „ihn zerstören“; Claude sollte standardmäßig `git checkout` anbieten, nicht `reset --hard`; Schutz wird in CLAUDE.md eingerichtet.
Die Bitte, „den aktuellen Stand zu speichern und zum letzten Push zurückzukehren“, kann zu diesen Befehlen führen: ```bash git stash save "WIP: Tracker enter/leave disabled + fsSyncModule fix" # saved uncommitted changes git reset --hard 35eb731 # destroyed commits d63695e..882e618 ``` Der erste Befehl war korrekt – er speicherte die nicht committeten Änderungen im Stash. Der zweite war destruktiv: Er setzte den Branch auf Commit `35eb731` zurück, und alle Commits zwischen diesem und `882e618` wurden verwaist. Standardmäßig bleiben verwaiste Commits in `.git/objects/`, bis `git gc` ausgeführt wird, was normalerweise innerhalb von zwei Wochen automatisch geschieht. Aber wenn du in dem Moment nicht wusstest, was zu tun ist, lief die Zeit bereits gegen dich. Die Logik ist einfach: In natürlicher Sprache bedeuten „zurückrollen“, „zurückgehen“, „wiederherstellen“, „revertieren“ und „rückgängig machen“ so viel wie „zurückblicken“ oder „an einen sicheren Ort zurückkehren“. Sie bedeuten nicht „den Verlauf zerstören“. Der Befehl `git reset --hard` zerstört ihn – er schreibt den Branch um und entfernt Commits aus der Menge der Commits, die über HEAD erreichbar sind. Eine sichere Alternative ist `git checkout `. Damit erhältst du einen abgetrennten HEAD und kannst den alten Zustand ansehen, ohne Branches anzutasten. Die wichtigste praktische Lehre ist, vor jeder größeren Aufgabe den aktuellen Stand mit `git commit` zu sichern, besonders vor dem Refactoring mehrerer Dateien. Ein Commit macht aus jedem Fehler von Claude einen einzigen `git checkout .`-Befehl, ohne dass Arbeit verloren geht. ## Wie rettet dich git reflog nach einem destruktiven Reset?
Das Wichtigste `git reflog` zeigt den lokalen Verlauf aller HEAD-Bewegungen im Repository – einschließlich Commits, die durch `git reset --hard` oder einen Force-Push entfernt wurden. Jede Bewegung wird standardmäßig 90 Tage lang gespeichert. Wenn Claude (oder du oder jemand anders) Commits mit einem destruktiven Befehl zerstört hat, zeigt `git reflog` deren Hashes, und du kannst den Branch mit `git reset --hard ` wiederherstellen.
Führe nach einem destruktiven Reset sofort `git reflog` aus: ```bash git reflog ``` Die Ausgabe sieht etwa so aus: ``` 35eb731 HEAD@{0}: reset: moving to 35eb731 882e618 HEAD@{1}: commit: middleware refactoring complete d63695e HEAD@{2}: commit: leaveRemove method finalized 1f9c8a3 HEAD@{3}: commit: tracker enter/leave disabled 35eb731 HEAD@{4}: pull origin main ``` `HEAD@{1}` bis `HEAD@{3}` sind genau diese „zerstörten“ Commits. Sie sind nicht aus dem lokalen Objektspeicher von git verschwunden, sondern lediglich über den Branch nicht mehr erreichbar. Um sie wiederherzustellen: ```bash # Create a branch from the last “destroyed” commit git branch recovered-work 882e618 # Or switch directly git reset --hard 882e618 ``` Danach enthält der Branch wieder den gesamten Verlauf bis zum Unglück. **Einschränkungen von Reflog:** 1. **Nur lokal.** Das Reflog wird in `.git/logs/HEAD` gespeichert und befindet sich nicht im Remote-Repository. Wenn du einen Force-Push ausführst und dann deine lokale Repository-Kopie löschst, verschwindet das Reflog mit dem Ordner. 2. **Standardmäßig 90 Tage.** Ältere Einträge können durch git gc entfernt werden. Du kannst die Frist mit `git config gc.reflogExpire 200.days.ago` einstellen. 3. **Deckt nicht ab, was nie in HEAD war.** Wenn ein Commit nur im Stash lag und der Stash zerstört wurde, zeigt das Reflog nur den letzten Zustand des Stashs, nicht seinen internen Verlauf. **Teamregel:** Führe `git gc --aggressive` niemals direkt nach einem Unglück aus. Untersuche zuerst das Reflog und stelle die Arbeit wieder her; alles andere kommt danach. Und lösche den lokalen Repository-Klon erst, wenn du sicher bist, dass alles, was du brauchst, gepusht wurde. ## Wie schützt du ein Projekt in CLAUDE.md vor destruktiven git-Befehlen?
Das Wichtigste Füge in die `CLAUDE.md` deines Projekts einen Anweisungsblock ein, der festlegt, welche git-Befehle Claude selbstständig ausführen darf, für welche es eine ausdrückliche Bestätigung braucht und welche ohne eine genaue Formulierung des Nutzers verboten sind. Claude behandelt CLAUDE.md als System-Prompt des Projekts und befolgt diese Regeln standardmäßig. So werden aus einem „gefährlichen“ Prompt zwei sichere Befehle.
Die Schwachstelle besteht darin, dass Claude standardmäßig keinen Schutzkontext hat. Es interpretiert „zurückrollen“ als `git reset --hard`, weil das technisch eine gültige Methode ist. Füge den Schutz in `CLAUDE.md` ein – der Datei mit dem System-Prompt des Projekts. **Minimale Regel** (in deine `CLAUDE.md` einfügen): ```markdown ## Git Safety Protocol - NIEMALS destruktive git-Befehle ausführen (push --force, reset --hard, checkout ., restore ., clean -f, branch -D), außer ich fordere diese Aktionen ausdrücklich an. Nicht autorisierte destruktive Aktionen sind nicht hilfreich und können zu verlorener Arbeit führen. - Wenn ich „roll back“, „go back“, „restore“, „revert“ oder „undo“ sage, interpretiere das als REVIEW-Befehle: Verwende `git log`, `git diff`, `git checkout ` (erstellt einen abgetrennten HEAD) oder `git stash` (bewahrt Änderungen auf). - IMMER vor JEDEM Befehl um Bestätigung bitten, der: - die HEAD-Position auf einen anderen Commit eines Branches verschiebt - den Commit-Verlauf ändert - nicht committete Arbeit verlieren könnte - die Flags --hard, --force, --aggressive enthält - Vor jedem destruktiven Befehl eine nummerierte Gegenüberstellung ausgeben: - SICHER: `git checkout ` verwenden, um den Zustand vorübergehend anzusehen - DESTRUKTIV: `git reset --hard` verwenden, um den Zustand dauerhaft zu zerstören - Vor der Ausführung meine ausdrückliche Entscheidung abwarten. ``` **Erweiterte Regel** für das Team (in die `CLAUDE.md` im Stammverzeichnis des Repositorys einfügen): ```markdown ## Git Workflow Rules - Bei jedem funktionierenden Meilenstein committen. Vor einem WIP-Commit `git status` und `git diff` prüfen, ausschließlich ausdrücklich geprüfte benannte Dateien mit `git add -- path/to/file` vormerken und den vorgemerkten Diff kontrollieren. Ein Timer erinnert an die Prüfung, erlaubt aber nicht das Vormerken des gesamten Arbeitsbaums. - Claude darf für Commits niemals `git add .` oder `git add -A` verwenden. Nur Dateien namentlich angeben, und zwar erst nach `git status` + `git diff`. - Vor `git push --force` zu main anhalten und mich fragen. In Feature-Branches Force-Pushes vorsichtig ausführen und nur, wenn du sicher bist, dass ich bereit bin, die vorherige Version zu verlieren. - Beim Auflösen von Merge-Konflikten niemals sofort „ours“ oder „theirs“ auswählen – zeige mir zuerst beide Versionen, dann entscheide ich. - `.gitignore` muss `.env*`, `.claude/personal/`, `node_modules/`, `dist/` enthalten. Wenn sie fehlen, hinzufügen. ``` Nach dem Hinzufügen dieser Blöcke würde der nächste Satz „zum letzten Push zurückrollen“ zu folgender Antwort führen: > Ich sehe 3 nicht committete Dateien und 4 Commits seit dem letzten Push. Zwei Möglichkeiten: > > 1. SICHER: Erstelle mit `git checkout ` einen `view-last-push`-Branch – ich bewahre die gesamte Arbeit auf, zeige aber vorübergehend den Stand des Pushs. > 2. DESTRUKTIV: `git reset --hard ` – ich zerstöre dauerhaft 4 Commits und die nicht committeten Änderungen. Sie lassen sich nur innerhalb von 90 Tagen über `git reflog` wiederherstellen. Wie entscheidest du dich? Das dauert eine halbe Minute Gespräch statt vier Stunden verlorener Arbeit. ## Welche 5 Möglichkeiten gibt es, in Claude Code rückgängig zu machen, und wie wählst du die richtige?
Das Wichtigste Wenn etwas schiefläuft, gibt es fünf Eskalationsstufen: `/rewind` (innerhalb einer Sitzung), `git checkout .` (nicht committete Änderungen), `git checkout ` (zu einem alten Commit zurückkehren, ohne den Verlauf zu verlieren), `git reset --hard ` (Branch zurücksetzen und die davor liegenden Commits verlieren), `git reflog` + Wiederherstellung (Katastrophe, alles ist weg). Jede Stufe ist schwerwiegender und gefährlicher als die vorherige.
Das Szenario „Claude hat etwas kaputtgemacht, ich muss es dringend wiederherstellen“ durchläuft diese Leiter von unten nach oben. Beginne immer bei Stufe 1. **Stufe 1. `/rewind` – sofortiges Rückgängigmachen innerhalb einer Sitzung.** Drücke `Esc Esc` oder gib `/rewind` ein. Wähle den Punkt vor dem Fehler. Wähle einen Modus (meist `Restore code and conversation`). Eine Sekunde später bist du wieder in der Vergangenheit und kannst neu beginnen. Deckt 80 % der Fälle ab, in denen „Claude das Falsche getan hat“. **Stufe 2. `git checkout .` – alle nicht committeten Änderungen rückgängig machen.** ```bash git diff # first see what actually changed git checkout . # undo all uncommitted changes in all files # or selectively: git checkout -- path/to/file.ts # only one file ``` Nützlich, wenn `/rewind` nicht funktioniert hat (zum Beispiel, weil Claude Dateien über Bash angefasst hat) oder du Änderungen außerhalb des Sitzungsverlaufs rückgängig machen musst. Alle nicht committeten Änderungen verschwinden dauerhaft. Falls du das bereuen könntest, führe zuerst `git stash` aus (siehe Stufe 2.5). **Stufe 2.5. `git stash` – Änderungen auf die Ablage legen.** ```bash git stash save "might still need this" # return to a clean state (without changes) # ... # if you change your mind—restore from stash: git stash pop ``` Ein guter Kompromiss zwischen „für immer verlieren“ und „unverändert lassen“. Der Stash bleibt lokal, bis er ausdrücklich gelöscht wird. **Stufe 3. `git checkout ` – zu einem alten Commit zurückkehren, ohne den Verlauf zu verlieren.** ```bash git log --oneline # find the hash of the right commit, e.g. abc1234 git checkout abc1234 # detached HEAD—view without changing anything # like the state? create a branch from it: git checkout -b recovery abc1234 # return: git checkout main ``` Das ist eine sichere „vorübergehende Rückkehr“. Der abgetrennte HEAD ändert den Branch nicht; deine aktuelle Arbeit in `main` (oder einem anderen Branch) bleibt intakt. Wenn du mit diesem Zustand weiterarbeiten möchtest, erstelle einen Branch. **Stufe 4. `git reset --hard ` – den Branch auf einen bestimmten Punkt zurücksetzen.** ⚠️ Destruktiv. Commits, die nach dem angegebenen Hash liegen, werden verwaist. ```bash git reflog # note the hash of the current state git reset --hard abc1234 # rewrite the branch # found a mistake? return through reflog: git reset --hard HEAD@{1} # to where you were before the reset ``` Verwende das nur, wenn du sicher bist, dass du die danach liegenden Commits nicht brauchst. Und prüfe `git reflog` immer VOR dem Zurücksetzen, damit du weißt, wohin du zurückkehren kannst, falls du es dir anders überlegst. **Stufe 5. `git reflog` + Wiederherstellung – ein katastrophales Szenario.** Jemand (Claude, du, ein Kollege) hat bereits `git reset --hard` oder einen Force-Push ausgeführt und die Arbeit gelöscht. Was kannst du tun? ```bash git reflog # look for the last hash before the disaster git branch recovered HEAD@{N} # create a branch from it git checkout recovered # switch to it git diff main # compare with the current state git checkout main && git merge recovered # restore into main, if you're sure ``` Falls das Reflog bereits bereinigt wurde (standardmäßig nach 90 Tagen), bleibt als letzter Ausweg `git fsck --lost-found`. Damit werden verwaiste Commits in `.git/objects/` angezeigt. Das ist beinahe Archäologie, aber manchmal funktioniert es. **Regel zur Wahl der Stufe:** | Was passiert ist | Stufe | |-----------------------------------------------|-----------------------------| | Claude hat 3 Dateien falsch umgeschrieben | 1\. `/rewind` | | Ich habe es ausprobiert, es gefiel mir nicht, die Sitzung hilft nicht | 2\. `git checkout .` | | Ich habe es manuell kaputtgemacht, möchte es nicht verlieren und könnte es wiederherstellen | 2.5. `git stash` | | Ich habe committet und muss einen Commit zurückgehen | 3\. `git checkout ` | | Ich bin sicher, dass ich die davor liegenden Commits nicht brauche | 4\. `git reset --hard` | | Ich habe es bereits mit einem destruktiven Befehl gelöscht | 5\. `git reflog` | ## Wie schützt du ein Projekt, damit es nichts rückgängig zu machen gibt?
Das Wichtigste Am besten ist es, gar nichts rückgängig machen zu müssen. Drei Schutzregeln: alle 30 Minuten den Fortschritt prüfen und einen funktionierenden Meilenstein mit ausdrücklich benannten geprüften Dateien committen; die erforderlichen Zeilen `.claude/personal/` und `.env*` in `.gitignore` eintragen; größere Experimente in einem separaten Branch mit `git checkout -b experiment-` durchführen. Das verkleinert die Wiederherstellungslücke für committete Dateien. Externe Systeme und nicht committete Arbeit brauchen weiterhin eigene Wiederherstellungspläne.
**Regel 1. Alle 30 Minuten committen.** Warte nicht, bis „die Aufgabe erledigt ist“. Committe jeden Zwischenschritt, der funktioniert. Commit-Nachrichten können beliebig sein; wichtig ist, dass Claude (oder du) mit einem einzigen `git checkout`-Befehl zu einem funktionierenden Zustand zurückkehren kann. ```bash # at the beginning of a task git status # alle vorgemerkten und übrigen Pfade prüfen git diff # Änderungen prüfen # Beispielpfad durch die tatsächlich geprüfte Datei ersetzen. git add -- path/to/file.ts git diff --cached # genauen Commitinhalt prüfen git commit -m "wip: starting User schema migration" # after 30 minutes (or after the first working iteration) git status git diff git add -- path/to/file.ts # tatsächlich geprüfter Pfad, kein Verzeichnisjoker git diff --cached git commit -m "wip: User schema is ready, migration applied locally" # at the end of the task—a meaningful commit git reset --soft HEAD~2 # combine the three wip commits into one git commit -m "feat(auth): add lastLoginAt field to User table" ``` Auch eine PostToolUse-Erinnerung muss dieselbe Prüfung und ausdrückliche Pfadauswahl beibehalten. Mache aus einem Timer keinen ungeprüften Auto-Commit: Sonst können fremde Änderungen oder bereits vorgemerkte Dateien in den Commit geraten. **Regel 2. Minimales `.gitignore`.** Diese Zeilen sind im Projektstamm erforderlich: ```gitignore # secrets .env .env.local .env.*.local # local Claude Code settings (not pushed to the team repository) .claude/personal/ .claude/sessions/ .claude/file-history/ # dependencies and build node_modules/ dist/ .next/ build/ ``` Ich verwende den Ordner `.claude/personal/` für meine eigenen Experimente und Notizen, die nicht in das gemeinsame Repository aufgenommen werden dürfen. Die Ordner `.claude/sessions/` und `.claude/file-history/` sind der lokale Speicher von Claude Code; sie gehören nicht ins Repository, belegen viel Speicherplatz und sind an eine bestimmte Maschine gebunden. **Regel 3. Experimente in einem separaten Branch.** Wenn die Aufgabe groß ist (Refactoring von 10+ Dateien, Migration zu einer neuen Datenbank, Neuschreiben eines Moduls), arbeite nicht auf dem Hauptbranch: ```bash git checkout -b experiment/auth-rewrite # work, commit every 30 minutes # if it works: git checkout main git merge experiment/auth-rewrite # if it doesn't: git checkout main git branch -D experiment/auth-rewrite # delete the branch # that's it, the main branch is intact ``` Diese einfache Gewohnheit macht aus „Claude hat das Projekt ruiniert“ ein „Claude hat einen Branch ruiniert, ich habe ihn gelöscht und wir fangen neu an“. **Regel 4. Vor gefährlichen Vorgängen `git tag` verwenden.** Erstelle vor einer Datenbankmigration, einem großen Refactoring oder einer Abhängigkeitsaktualisierung einen Tag: ```bash git tag pre-prisma-migration-v2 # work # something went wrong: git reset --hard pre-prisma-migration-v2 # or just take a look: git checkout pre-prisma-migration-v2 ``` Ein Tag ist ein benannter Zeiger auf einen Commit, den du selbst nach der Bereinigung des Reflogs nicht verlierst. ## Wie geht es weiter: Wie passt Rückgängigmachen in Context Engineering?
Das Wichtigste Rückgängigmachen ist keine eigenständige Fähigkeit, sondern Teil der Verwaltung des Claude-Code-Sitzungskontexts. Wenn du weißt, wann du `/rewind` drücken, wann du `git commit` und wann du `git stash` verwenden solltest, verwaltest du einen ganzen Arbeitsablauf, nicht nur einen Befehl. Das ist Teil des **Context Engineering**. Ohne es verhält sich Claude wie ein gewöhnlicher Assistent; mit ihm wie ein berechenbares Werkzeug.
Diese drei Ebenen des Rückgängigmachens bilden die Grundlage für eine Fähigkeit: zu wissen, wie man einen Zustand wiederherstellt, wenn etwas kaputtgeht. Für sich genommen ist diese Fähigkeit eng umrissen. Doch in Verbindung mit weiteren Werkzeugen des Context Engineering wird daraus etwas Größeres. Der Plan Mode lässt dich nicht sofort Code schreiben – zuerst kommt der Plan, dann die Bestätigung, dann die Ausführung. Das ist vorbeugendes Rückgängigmachen: Du schreibst nichts, was du später rückgängig machen musst, weil der Plan im Voraus geprüft wurde. Mehr dazu im Leitfaden zu [Plan Mode in Claude Code](https://ailoot.ai/blog/de/claude-code-plan-mode/). [CLAUDE.md](https://ailoot.ai/blog/de/claude-md-template/) legt Regeln fest, die Claude standardmäßig befolgt, darunter das oben beschriebene Git Safety Protocol. Das ist ein vorbeugender Schutz vor destruktiven Befehlen. Das [Second Brain](https://ailoot.ai/blog/de/claude-code-second-brain/) gibt Claude sitzungsübergreifend Wissen über das Projekt – es weiß, welchen Code du hast, wie die Geschäftslogik aussieht und welche Vereinbarungen früher getroffen wurden. Je mehr Wissen, desto geringer die Wahrscheinlichkeit, dass es das Falsche tut. [Skills und Subagents](https://ailoot.ai/blog/de/claude-code-skills-library/) sind deine Methodik in Codeform. Wenn der richtige git-Arbeitsablauf in einem Skill verankert ist, führt kein Subagent `git reset --hard` ohne Bestätigung aus. All das zusammen ist **Context Engineering**. Verwalte den Kontext vor dem Prompt, nicht währenddessen. Mehr dazu in [Was ist Context Engineering](https://ailoot.ai/blog/de/context-engineering/). Rückgängigmachen ist die letzte Verteidigungslinie. Plan Mode + CLAUDE.md + Second Brain + Skills sind die ersten vier. Wenn sie eingerichtet sind, ist Rückgängigmachen selten und schnell erledigt. Wenn nicht, wird es zum täglichen Ritual.
### Quellen - [Anthropic Docs - Checkpointing](https://code.claude.com/docs/en/checkpointing) - [Anthropic Docs - What's new (Week 20, 11-15 May 2026)](https://code.claude.com/docs/en/whats-new) - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Git Reference - reflog](https://git-scm.com/docs/git-reflog)
Rückgängigmachen beginnt dort, wo Planung endet. [Zu Ailoot](https://ailoot.ai/). ## Fragen und Antworten ### Sollte ich für einen WIP-Checkpoint git add . verwenden? Nein. Prüfe `git status` und `git diff`, merke nur benannte geprüfte Dateien vor und kontrolliere `git diff --cached` vor dem Commit. Ein regelmäßiger Checkpoint erlaubt keine Aufnahme fremder oder vorher vorgemerkter Änderungen. ### Kann /rewind eine Datenbankmigration oder entfernte API-Aktion rückgängig machen? Nein. Checkpoints betreffen laut Leitfaden unterstützte Dateiänderungen der Sitzung. Datenbank-, Remote-Git- und API-Effekte brauchen eigene Wiederherstellungsschritte. Nutze Git oder Backups für Dateien außerhalb der Checkpointabdeckung. ## Ailoot · Das Unternehmen und sein Projektportfolio Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle. Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe. Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.