Git für KI 2, Branches und Reviews

Worum es geht

Lesson 1 hat Dir das Sicherheitsnetz gegeben. Diese Lesson bringt Dich auf das Niveau wo Du wirklich entspannt mit der KI arbeitest. Drei Dinge: Branches als Sandbox, Diffs lesen bevor Du committest, und warum Du Rollbacks nie blind der KI überlassen solltest.

Warum Branches existieren

Stell Dir vor Du hast ein laufendes Projekt. Login funktioniert, Bezahlung funktioniert, alles gut. Jetzt willst Du Claude eine neue Funktion bauen lassen, sagen wir einen Dark Mode.

Dark Mode ist eine kleine Änderung, denkst Du. Was kann schon schiefgehen?

In der Praxis: Claude ändert das Theme-System, berührt aber gleichzeitig das CSS-Layout, packt eine neue Library dazu, und plotzlich sieht der Login-Screen kaputt aus. Wenn Du das alles direkt auf Deinem Haupt-Stand gemacht hast, hast Du jetzt zwei Probleme statt eines.

Die Lösung sind Branches. Ein Branch ist eine Parallel-Version Deines Projekts, in der Du was ausprobieren kannst ohne den Haupt-Stand anzufassen.

In der Speicherstand-Metapher: Branch ist wenn Du eine Kopie Deines Spielstands machst, bevor Du in den schwierigen Dungeon gehst. Wenn Du im Dungeon stirbst und die Kopie nicht magst, löschst Du sie. Dein Original ist unberührt.

Branch-per-Ask, das wichtigste Pattern

Die Regel ist einfach. Vor jedem größeren KI-Auftrag legst Du einen neuen Branch an.

In GitHub Desktop oben in der Mitte ist ein Branch-Dropdown, klick drauf und dann "New branch". Name eintragen, zum Beispiel feature/dark-mode. Klick.

Du bist jetzt auf einem neuen Branch. Alles was Du oder die KI hier macht, berührt Deinen Haupt-Stand (main) nicht.

Jetzt lässt Du die KI bauen.

Drei mögliche Ausgänge:

1. Es funktioniert und sieht gut aus. Du committest, gehst zurück auf main, mergst den Branch rein. Fertig.
2. Es funktioniert halb, Du willst weiterarbeiten. Du committest auf dem Branch, machst weiter, mergst später wenn alles passt.
3. Es ist Murks. Du gehst auf main zurück, löschst den Branch, gehst Mittagessen.

Variante 3 ist warum Branches existieren. Ohne Branch waerst Du jetzt am Aufräumen. Mit Branch hast Du nichts verloren.

Diff lesen, der unterschätzte Move

Ein Diff ist die Liste aller Änderungen seit dem letzten Speicherstand. Welche Zeilen wurden hinzugefuegt, welche entfernt, in welcher Datei.

In GitHub Desktop siehst Du das automatisch. Du klickst links auf eine geänderte Datei, rechts siehst Du Zeile für Zeile was sich geändert hat. Gruen ist neu, rot ist weg.

Bevor Du irgendwas committest, schau Dir den Diff an. Eine Minute reicht.

Du suchst nach drei Dingen:

• Hat die KI Sachen geändert die Du nicht angefragt hast? Klassiker bei Claude und Cursor: Du fragst nach einer Funktion, die KI refactoriert nebenbei drei andere weil sie sie "schöner" findet. Diff zeigt Dir das.
• Sind Dateien verschwunden die Du brauchst? KI löscht manchmal Code den sie für "nicht genutzt" hält, der aber an einer anderen Stelle aufgerufen wird.
• Sind irgendwo Geheimnisse drin? API-Keys, Passwörter, .env-Inhalte. Wenn Du das committest und nach GitHub pushst, ist es für immer im Internet, auch wenn Du es später löschst. Diff fangen das ab.

Wenn der Diff sauber aussieht, committen. Wenn nicht, KI nochmal ranlassen oder die Änderungen verwerfen.

Pull Requests, auch wenn Du allein arbeitest

Pull Request klingt nach Team-Arbeit. Du kannst es aber auch für Dich allein nutzen, und es lohnt sich.

Workflow:

1. Du bist auf einem Branch (z.B. feature/dark-mode), Änderungen sind drin.
2. Du pushst den Branch zu GitHub (Klick in GitHub Desktop).
3. Auf github.com siehst Du oben einen Hinweis "compare and pull request". Klicken.
4. Du landest auf einer Seite die Dir den ganzen Diff groß und lesbar zeigt.
5. Du kannst kommentieren, abnicken, mergen.

Was Du davon hast: Du siehst die Änderungen nochmal in einer ganz anderen Ansicht. Manchmal fällt einem in der Browser-Ansicht etwas auf, was man im Editor übersehen hat. Plus Du hast eine schöne Historie auf GitHub mit Beschreibungen warum Du was gemacht hast.

Die Falle, Claude und git reset --hard

Jetzt zu einer Warnung die in fast keinem Anfänger-Tutorial steht.

Wenn Du zu Claude Code sagst "kannst Du das rückgängig machen", kann es passieren dass Claude git reset --hard ausführt. Das ist ein zerstörerischer Befehl. Er löscht alles seit dem letzten Commit ohne Wiederherstellungsmöglichkeit. Wenn Du in den letzten zwei Stunden Änderungen drin hattest die Du nicht committed hast, sind die jetzt weg.

Es gibt einen offiziellen Bug-Report dazu im claude-code Repo (Issue 17190 vom Januar 2026) wo genau das passiert ist und der Reporter Stunden Arbeit verloren hat.

Was Du stattdessen machen solltest:

• Wenn Du zurück zu einem frueheren Commit willst, mach das selber in GitHub Desktop. Rechtsklick auf den Commit, "Revert this commit". Das ist der sichere Weg, alle Änderungen bleiben in der Historie, der Revert ist selber ein neuer Commit.
• Wenn Du in Claude Code bist und nur die letzten Änderungen rückgängig machen willst, nutze den eingebauten /rewind Befehl (auch als /checkpoint aliased). Das ist Claudes eigenes sicheres Sicherheitsnetz, es macht Code UND Conversation rückgängig zum gewählten Punkt.
• Wenn Du Claude eine spezifische Aufgabe zum Aufräumen geben willst, sei konkret. "Lösche die letzten Änderungen in src/auth.ts und stelle den Stand von Commit a3b4c5 wieder her" ist viel sicherer als "mach das rückgängig".

Faustregel: Rollbacks werden in der GUI gemacht oder mit /rewind. Niemals als unklarer Auftrag an die KI.

Commit-Disziplin

Eine letzte Sache. Mach mehr Commits, kürzer.

Anfänger machen oft den Fehler eine Stunde am Stück zu bauen und dann einen Riesen-Commit "alles fertig". Wenn dann was schiefgeht, ist der Commit so groß dass der Rollback alles wegnimmt was Du in der Stunde gemacht hast.

Besser: alle 15 bis 30 Minuten committen, oder immer wenn ein kleiner Schritt fertig ist. Eine schöne Anfänger-Regel ist: vor JEDEM Auftrag den Du an die KI gibst einmal kurz committen. So hast Du immer einen Speicherstand kurz vor der nächsten Änderung.

Was Du jetzt kannst

• Branches anlegen und Branch-per-Ask Pattern anwenden
• Diffs lesen und drei typische KI-Probleme drin erkennen
• Pull Requests für den Solo-Use einsetzen
• Sichere von zerstoererischen Rollback-Befehlen unterscheiden
• Sinnvolle Commit-Frequenz finden

In Lesson 3 zeigen wir Dir den Profi-Move: den GitHub MCP Server. Damit kann Claude Code direkt mit Deinem GitHub-Account reden, Issues lesen, Pull Requests anlegen, CI-Fehler debuggen.