Git fuer 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 ueberlassen 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 Aenderung, denkst Du. Was kann schon schiefgehen?

In der Praxis: Claude aendert das Theme-System, beruehrt 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 Loesung 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, loeschst Du sie. Dein Original ist unberuehrt.

Branch-per-Ask, das wichtigste Pattern

Die Regel ist einfach. Vor jedem groesseren 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, beruehrt Deinen Haupt-Stand (main) nicht.

Jetzt laesst Du die KI bauen.

Drei moegliche Ausgaenge:

1. Es funktioniert und sieht gut aus. Du committest, gehst zurueck auf main, mergst den Branch rein. Fertig.
2. Es funktioniert halb, Du willst weiterarbeiten. Du committest auf dem Branch, machst weiter, mergst spaeter wenn alles passt.
3. Es ist Murks. Du gehst auf main zurueck, loeschst den Branch, gehst Mittagessen.

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

Diff lesen, der unterschaetzte Move

Ein Diff ist die Liste aller Aenderungen 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 geaenderte Datei, rechts siehst Du Zeile fuer Zeile was sich geaendert 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 geaendert die Du nicht angefragt hast? Klassiker bei Claude und Cursor: Du fragst nach einer Funktion, die KI refactoriert nebenbei drei andere weil sie sie "schoener" findet. Diff zeigt Dir das.
• Sind Dateien verschwunden die Du brauchst? KI loescht manchmal Code den sie fuer "nicht genutzt" haelt, der aber an einer anderen Stelle aufgerufen wird.
• Sind irgendwo Geheimnisse drin? API-Keys, Passwoerter, .env-Inhalte. Wenn Du das committest und nach GitHub pushst, ist es fuer immer im Internet, auch wenn Du es spaeter loeschst. Diff fangen das ab.

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

Pull Requests, auch wenn Du allein arbeitest

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

Workflow:

1. Du bist auf einem Branch (z.B. feature/dark-mode), Aenderungen 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 gross und lesbar zeigt.
5. Du kannst kommentieren, abnicken, mergen.

Was Du davon hast: Du siehst die Aenderungen nochmal in einer ganz anderen Ansicht. Manchmal faellt einem in der Browser-Ansicht etwas auf, was man im Editor uebersehen hat. Plus Du hast eine schoene 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 Anfaenger-Tutorial steht.

Wenn Du zu Claude Code sagst "kannst Du das rueckgaengig machen", kann es passieren dass Claude git reset --hard ausfuehrt. Das ist ein zerstoererischer Befehl. Er loescht alles seit dem letzten Commit ohne Wiederherstellungsmoeglichkeit. Wenn Du in den letzten zwei Stunden Aenderungen 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 zurueck zu einem frueheren Commit willst, mach das selber in GitHub Desktop. Rechtsklick auf den Commit, "Revert this commit". Das ist der sichere Weg, alle Aenderungen bleiben in der Historie, der Revert ist selber ein neuer Commit.
• Wenn Du in Claude Code bist und nur die letzten Aenderungen rueckgaengig machen willst, nutze den eingebauten /rewind Befehl (auch als /checkpoint aliased). Das ist Claudes eigenes sicheres Sicherheitsnetz, es macht Code UND Conversation rueckgaengig zum gewaehlten Punkt.
• Wenn Du Claude eine spezifische Aufgabe zum Aufraeumen geben willst, sei konkret. "Loesche die letzten Aenderungen in src/auth.ts und stelle den Stand von Commit a3b4c5 wieder her" ist viel sicherer als "mach das rueckgaengig".

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, kuerzer.

Anfaenger machen oft den Fehler eine Stunde am Stueck zu bauen und dann einen Riesen-Commit "alles fertig". Wenn dann was schiefgeht, ist der Commit so gross 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 schoene Anfaenger-Regel ist: vor JEDEM Auftrag den Du an die KI gibst einmal kurz committen. So hast Du immer einen Speicherstand kurz vor der naechsten Aenderung.

Was Du jetzt kannst

• Branches anlegen und Branch-per-Ask Pattern anwenden
• Diffs lesen und drei typische KI-Probleme drin erkennen
• Pull Requests fuer 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.