Ein KI-Agent kann an einem Nachmittag die Hälfte eines Projekts umbauen. Er kann aber auch ein Stylesheet löschen, eine Konfigurationsdatei überschreiben oder einen Ordner in einem Zustand hinterlassen, an den sich niemand erinnert. Liegt die einzige Kopie auf einem Laptop, kosten eine defekte Festplatte oder ein falscher Prompt schnell Tage. Die praktische Frage ist also: Was holt dein Projekt wirklich zurück?
Git und GitHub: zwei verschiedene Aufgaben
Git ist eine Versionsverwaltung: ein Programm, das Momentaufnahmen deines Projekts speichert, sogenannte Commits. Jeder Commit ist ein gesicherter Stand, zu dem du später zurückkehren kannst. GitHub ist ein Dienst, der Git-Repositorys hostet. Ein Repository ist der Projektordner samt vollständiger Historie. Wenn du deine Commits zu GitHub pushst, liegt eine zweite Kopie dieser Historie auf einem Server außerhalb deines Rechners.
Dabei zählt die Sichtbarkeit. Laut GitHub-Dokumentation sind private Repositorys nur für dich, für Personen, denen du ausdrücklich Zugriff gibst, und bei Organisationen für bestimmte Mitglieder zugänglich. Öffentliche Repositorys kann jeder im Internet sehen. Admins können die Sichtbarkeit später ändern. Für ein persönliches Projekt oder einen internen Agenten ist privat die vernünftige Voreinstellung.
Was Checkpoints und /rewind in Claude Code rückgängig machen
Claude Code hat ein eigenes Sicherheitsnetz. Vor jedem Prompt, der einen neuen Durchgang startet, hält es den Zustand der Dateien fest, die Claude mit seinen Dateibearbeitungswerkzeugen ändert. Das Rewind-Menü öffnest du mit /rewind oder mit zweimal Esc bei leerer Eingabe. Dort stellst du Code und Unterhaltung, nur die Unterhaltung oder nur den Code wieder her. Checkpoints werden mit der Unterhaltung gespeichert und überstehen das Fortsetzen einer Sitzung.
Die Grenzen sind ebenso klar dokumentiert. Eine Datei, die nur über Bash-Befehle geändert wurde, wird nicht verfolgt. Manuelle Änderungen außerhalb von Claude Code und Änderungen aus parallelen Sitzungen werden normalerweise nicht erfasst. Änderungen der meisten Subagenten werden nicht wiederhergestellt. Claude Code behält Datei-Snapshots für die 100 jüngsten Checkpoints einer Sitzung und löscht sie standardmäßig etwa 30 Tage nach dem letzten gespeicherten Snapshot.
Warum du trotzdem committen solltest
Die Dokumentation beantwortet das direkt: Checkpoints dienen der schnellen Wiederherstellung innerhalb einer Sitzung. Für Commits, Branches und eine dauerhafte Historie empfiehlt sie weiterhin eine Versionsverwaltung wie Git. Rewind ist eine Rückgängig-Taste für eine Arbeitssitzung. Ein zu GitHub gepushter Commit existiert unabhängig von dieser Sitzung und von deinem Laptop.
Deshalb konkurrieren die beiden nicht. Nutze Rewind, wenn die letzten Prompts danebengingen. Hol dir den Stand von GitHub, wenn der Schaden größer ist, wenn du den Rechner wechselst oder wenn der Ordner selbst weg ist. Eine praktische Gewohnheit: an jedem stabilen Punkt committen und den Agenten anweisen, das nach jeder wichtigen Änderung oder am Tagesende zu tun.
API-Schlüssel aus dem Repository heraushalten
Viele Projekte speichern Geheimnisse wie API-Schlüssel oder Datenbank-Zugangsdaten in einer .env-Datei. Diese Datei gehört nicht ins Repository. Das übliche Werkzeug ist .gitignore, eine Datei mit Pfaden, die Git ignorieren soll. Das Git-Handbuch ist beim Geltungsbereich genau: Sie legt absichtlich nicht verfolgte Dateien fest, und bereits von Git verfolgte Dateien sind nicht betroffen.
Kleines Detail, großer Unterschied. Wurde eine .env-Datei einmal committet, nimmt ein späterer Eintrag in .gitignore sie nicht aus der Verfolgung. Laut Handbuch entfernst du sie zuerst mit git rm --cached aus dem Index und trägst sie dann in .gitignore ein. Da ignorierte Dateien nie gepusht werden, brauchst du für deine Geheimnisse eine eigene, sichere Sicherung.
Einschätzung der Redaktion
Die Tatsache: Checkpoints und Git decken unterschiedliche Zeiträume ab, und die Dokumentation von Claude Code sagt selbst, dass Rewind keine Versionsverwaltung ersetzt. Meine Schlussfolgerung: Der heikle Moment ist nicht der erste Commit, sondern der erste Push. Prüfe davor die Sichtbarkeit des Repositorys und ob .env wirklich nicht verfolgt wird, nicht nur in .gitignore steht. Ein Agent kann diese Schritte für dich ausführen, das Ergebnis solltest du trotzdem selbst kontrollieren.
