Eine Stunde zurück

Was es ist und warum es zählt

Das passiert jedem. Du bittest Claude um eine Änderung, er macht zehn, und eine Stunde später startet die App nicht mehr. Du weißt nicht, was er angefasst hat, und erinnerst dich nicht, wie es vorher war.

Git ist die Geschichte des Projekts. Jedes Mal, wenn du mit einem Commit speicherst, machst du ein Foto aller Dateien in diesem Moment. Wenn etwas kaputtgeht, gehst du zu einem früheren Foto zurück. Aber nur zu einem Foto, das es gibt: Wenn du nicht gespeichert hast, gibt es kein Vorher, zu dem du zurückkannst.

Die Git-Befehle musst du nicht lernen. Die schreibt Claude. Dir reichen drei Sätze, genau so, wie sie sind, in den drei richtigen Momenten: bevor du anfängst, wenn etwas kaputtgeht, vor einer großen Sache.

Voraussetzung ist nur, dass das Projekt Git nutzt. Wenn nicht, bitte Claude, es einzurichten: Das ist eine Zeile.

1. Bevor du anfängst: speichern

Bevor ich Claude eine Aufgabe gebe, schreibe ich das:

Bevor du irgendetwas anfasst, speichere den aktuellen Stand des Projekts mit einem Commit, damit wir hierher zurückkönnen.

Claude macht einen Commit: Er speichert den aktuellen Stand mit einer Nachricht, die sagt, was drin ist. Dieser Commit wird zum sicheren Punkt. Was auch immer danach passiert, dorthin kannst du zurück.

Ich mache das auch mitten in der Arbeit, wenn ein Teil funktioniert. Je mehr Fotos du machst, desto näher ist der Punkt, zu dem du zurückkannst. Wenn der letzte Commit von gestern ist, heißt zurückgehen, alles zu verlieren, was du heute gemacht hast.

2. Wenn etwas kaputtgeht: zurückgehen

Wenn die App nicht mehr geht und ich nicht verstehe, warum, bitte ich Claude nicht, die Reparatur der Reparatur zu reparieren. Ich schreibe:

Geh zurück zu dem Stand von vor einer Stunde. Speichere vorher, was noch nicht gespeichert ist, und lösch nichts aus der Historie: Ich will es mir anders überlegen können.

Der Satz hat drei Teile, und jeder zählt.

• „Geh zurück zu dem Stand von vor einer Stunde“: Claude schaut sich die Historie des Projekts an und sucht den letzten Commit vor diesem Moment. Du kannst auch „zu gestern Abend“ oder „zu der Zeit, bevor du den Login angefasst hast“ sagen.
• „Speichere vorher, was noch nicht gespeichert ist“: Änderungen, die in keinem Commit sind, sind am empfindlichsten. Claude bringt sie in Sicherheit, bevor er etwas tut, mit einem Commit oder mit git stash, das sie zur Seite legt, damit du sie später wieder holen kannst.
• „Lösch nichts aus der Historie“: So nutzt Claude git revert, das die falschen Commits nicht löscht, sondern einen neuen hinzufügt, der sie rückgängig macht. Die ganze Historie bleibt erhalten: Wenn du merkst, dass ein Teil der Arbeit der letzten Stunde gut war, holst du ihn zurück.

Das Gegenteil ist git reset --hard. Es setzt das Projekt zurück und wirft die nicht gespeicherten Änderungen in den Dateien weg, ohne Papierkorb. Manchmal braucht man das, aber es ist der Befehl, mit dem Arbeit verloren geht. Deshalb steht in meinem Satz „Ich will es mir anders überlegen können“.

Wenn er fertig ist, bitte ich um eine Bestätigung:

Sag mir, zu welchem Commit du zurückgegangen bist, was du rückgängig gemacht hast, und lass die Tests laufen, um zu sehen, ob es jetzt funktioniert.

3. Vor einer großen Sache: ein neuer Branch

Den Login neu bauen, die Datenbank ändern, eine ganze Seite neu schreiben: Bei solchen Aufgaben kann mittendrin etwas schiefgehen. Bevor ich anfange, schreibe ich:

Mach diese Arbeit auf einem neuen Branch. Wenn es funktioniert und die Tests durchlaufen, führ ihn mit dem Hauptbranch zusammen. Wenn es nicht funktioniert, wirf den Branch weg und geh zurück zum guten.

Ein Branch ist eine parallele Version des Projekts. Claude arbeitet darauf, macht seine Commits, und die Hauptversion, meistens main, bleibt, wie sie war. Wenn die Arbeit funktioniert, führt er sie zusammen: Das ist der Merge, die Änderungen des Branches kommen in die Hauptversion. Wenn nicht, wirft er den Branch weg und du bist wieder am guten Punkt.

„Die Tests laufen durch“ ist der Teil, auf den es ankommt. Ohne Prüfung heißt „es funktioniert“ nur, dass es für Claude fertig aussieht. Wenn das Projekt keine Tests hat, bitte ihn wenigstens, die App zu starten und dir zu sagen, wie er geprüft hat.

Ein Branch ändert die Dateien im selben Projektordner, also eine Aufgabe nach der anderen. Wenn du mehrere Claude-Sitzungen parallel willst, jede auf ihrem eigenen Branch, brauchst du Worktrees: einen eigenen Ordner für jeden Branch. Darüber schreibe ich in der Anleitung ALBERI (strikt.fit/alberi).

4. Dazu: die Checkpoints von Claude Code

Neben Git gibt es ein kleineres Netz, schon in Claude Code eingebaut. Jedes Mal, wenn du eine Nachricht schickst, merkt sich Claude Code den Stand der Dateien, die Claude mit seinen eigenen Werkzeugen bearbeitet. Diese Punkte heißen Checkpoints, und Claude Code legt sie von selbst an.

Um zu einem dieser Punkte zurückzugehen, drück zweimal Esc bei leerem Eingabefeld, oder schreib /rewind. Steht Text im Feld, löscht das doppelte Esc nur den Text. Es öffnet sich die Liste der Nachrichten, die du geschickt hast: Wähl den Punkt und was wiederhergestellt werden soll.

• Code und Unterhaltung: Du gehst mit beidem zu diesem Punkt zurück.
• Nur die Unterhaltung: Der Chat geht zu dieser Nachricht zurück, die Dateien bleiben, wie sie jetzt sind.
• Nur der Code: Die Dateien gehen zurück auf den alten Stand, die Unterhaltung bleibt.

Die beiden Code-Optionen erscheinen nur, wenn Claude nach diesem Punkt Dateien geändert hat.

Was sie nicht rückgängig machen

• Befehle im Terminal. Wenn Claude eine Datei mit rm oder mv löscht oder verschiebt, holt der Rewind sie nicht zurück.
• Änderungen außerhalb von Claude Code: Dateien, die du selbst im Editor änderst oder die eine andere Sitzung ändert, werden meistens nicht erfasst.

Wie lange sie halten

Checkpoints werden mit der Unterhaltung gespeichert. Wenn du das Terminal schließt und später dieselbe Sitzung fortsetzt, kannst du immer noch zurückspulen. Aber sie bleiben an diese Sitzung gebunden: Eine neue Sitzung startet ohne sie. Und standardmäßig löscht Claude Code die Dateikopien nach etwa 30 Tagen, zusammen mit den alten Daten der Sitzung.

Deshalb ersetzen sie Git nicht. Sie sind die Rückgängig-Taste der Sitzung. Die echte Geschichte des Projekts führt Git.

5. Eine Sicherheitsregel

Arbeit, die noch nicht gespeichert ist, ist die, die du wirklich verlieren kannst, und der häufigste Weg dahin ist ein Reset. Deshalb sagt jeder Satz Claude, dass er zuerst speichern soll. Du kannst hinzufügen:

Benutz git reset --hard nie, ohne mich zu fragen.

Wenn sie immer gelten soll, schreib sie in die CLAUDE.md des Projekts, die Datei, die Claude am Anfang jeder Sitzung liest. Es bleibt eine Anweisung: Claude hält sich daran, aber es ist keine Sperre. Für eine echte Sperre gibt es die Deny-Liste in den Einstellungen, die den Befehl stoppt, bevor er startet: Die erkläre ich in der Anleitung JEV (strikt.fit/jev).

Häufige Fehler

• Stundenlang ohne Commit arbeiten: Git geht nur zu Ständen zurück, die es gibt, also lass vor jeder Aufgabe speichern und immer dann, wenn ein Teil funktioniert.
• Die Reparatur endlos reparieren lassen: Nach zwei vergeblichen Versuchen geh zurück zum guten Punkt und fang mit einer klareren Anfrage neu an.
• Sich bei allem auf den Rewind verlassen: Er macht weder Terminal-Befehle noch Änderungen außerhalb von Claude Code rückgängig, also bleibt Git das echte Netz.
• Ein git reset --hard durchgehen lassen: Es wirft ungespeicherte Arbeit weg, also verlang git revert und vorher eine Sicherung.
• Eine große Sache direkt auf der Hauptversion machen: Fang sie auf einem neuen Branch an, dann wirfst du den Branch weg, wenn es schiefgeht, und verlierst nichts.
• Einen Branch ohne Prüfung zusammenführen: Lass die Tests vor dem Merge laufen, nicht danach.

Checkliste

• Das Projekt nutzt Git
• Commit vor jeder Aufgabe
• Commit, wenn ein Teil funktioniert
• Zum Zurückgehen: git revert, kein Reset
• Große Sachen auf einem neuen Branch
• Tests vor dem Zusammenführen des Branches
• Rewind nur für Claudes Änderungen in der Sitzung

Häufige Fragen