09-01-2026, 05:10 PM
Vibe Coding ohne Git ist wie Skifahren ohne Helm: spaessig, bis es schiefgeht. Hier meine Checkpoint-Strategie, die ich seit Wochen in JavaScript-Projekten anwende.
Regel 1: Commit vor dem Prompt
Bevor du eine groessere Aenderung an die KI delegierst: git commit mit kurzer Beschreibung des IST-Zustands. So kannst du nach einem schlechten Vibe-Pass immer zurueck.
Regel 2: Commit nach jedem gruenen Prompt
Funktioniert das Ergebnis im Browser? git add -A && git commit -m "vibe: <kurzer Prompt-Kontext>". Kein Push, lokal reicht. Die Commits sind deine Zeitmaschine.
Regel 3: Branch fuer experimentelle Vibes
Neues Feature, neue API, neues Design? git checkout -b vibe/<feature>. Wenn es nicht zieht: Branch loeschen, kein Verlust im Hauptzweig.
Regel 4: Diff, nicht lesen
Nach einem KI-Pass nie blind weiterbauen: git diff --stat und git diff auf die kritischen Dateien pruefen. Du liest nicht jede Zeile, aber du siehst, WAS geaendert wurde (und ob z. B. auch package.json angefasst wurde).
Regel 5: Die Tag-Regel
Vor einem Deploy oder wenn jemand anderes mitarbeiten soll: git tag vibe-v1. Ein bekannt-good Zustand, der immer zurueckholbar ist.
Minimal-Setup pro Projekt:
- .gitignore (node_modules, dist, .env)
- init + erster Commit mit README
- danach: Regeln 1-5 als Reflex
So bleibt der Vibe-Flow schnell, aber nichts geht verloren. Was ist eure Strategie mit Versionierung bei KI-Code?
Regel 1: Commit vor dem Prompt
Bevor du eine groessere Aenderung an die KI delegierst: git commit mit kurzer Beschreibung des IST-Zustands. So kannst du nach einem schlechten Vibe-Pass immer zurueck.
Regel 2: Commit nach jedem gruenen Prompt
Funktioniert das Ergebnis im Browser? git add -A && git commit -m "vibe: <kurzer Prompt-Kontext>". Kein Push, lokal reicht. Die Commits sind deine Zeitmaschine.
Regel 3: Branch fuer experimentelle Vibes
Neues Feature, neue API, neues Design? git checkout -b vibe/<feature>. Wenn es nicht zieht: Branch loeschen, kein Verlust im Hauptzweig.
Regel 4: Diff, nicht lesen
Nach einem KI-Pass nie blind weiterbauen: git diff --stat und git diff auf die kritischen Dateien pruefen. Du liest nicht jede Zeile, aber du siehst, WAS geaendert wurde (und ob z. B. auch package.json angefasst wurde).
Regel 5: Die Tag-Regel
Vor einem Deploy oder wenn jemand anderes mitarbeiten soll: git tag vibe-v1. Ein bekannt-good Zustand, der immer zurueckholbar ist.
Minimal-Setup pro Projekt:
- .gitignore (node_modules, dist, .env)
- init + erster Commit mit README
- danach: Regeln 1-5 als Reflex
So bleibt der Vibe-Flow schnell, aber nichts geht verloren. Was ist eure Strategie mit Versionierung bei KI-Code?