KI-generierte Commits verwalten

KI-generierte Commits verwalten

0:00 Eine Commit-Historie ist so etwas wie das Logbuch eines Projekts. Und wie jedes Logbuch nützt sie nur, wenn jemand sie später lesen kann. Genau hier haben KI-Agenten eine unangenehme Eigenschaft: Sie schreiben viel und sie schreiben gleichförmig. Fünf Einträge, die alle dasselbe sagen, sind schlimmer als einer, denn sie erwecken den Eindruck von Dokumentation, ohne welche zu sein.

0:21 In diesem Modul holen wir uns die Historie zurück. Wir finden den Commit, der einen Fehler eingeschleppt hat, korrigieren ihn nachträglich und verdichten das Ganze zu etwas, das in einem halben Jahr noch verständlich ist.

Ordnung in die Historie bringen

0:35 Drei Werkzeuge stehen im Mittelpunkt, und alle drei gibt es seit Jahren: bisect, interaktives Rebase und Squash. Neu ist nur der Anlass, sie zu benutzen. Wir beginnen mit einer Unterscheidung, die überraschend oft unterschätzt wird — der zwischen dem Chat mit dem Agenten und der Historie im Repository. Danach wird es handfest: suchen, korrigieren, verdichten.

0:56 Am Ende dieses Moduls haben Sie aus sieben nichtssagenden Einträgen drei aussagekräftige gemacht, ohne eine Zeile Code zu verlieren. Vier Fähigkeiten stehen am Ende. Sie halten Chat-Verlauf und Commit-Historie sauber auseinander und wissen, was in welchem festgehalten gehört. Sie finden mit bisect gezielt den Commit, der einen Fehler eingeführt hat, statt sich durch Diffs zu klicken.

1:19 Sie korrigieren einen zurückliegenden Commit, ohne die nachfolgenden von Hand nachzuziehen. Und Sie fassen eine Serie gleichförmiger Commits so zusammen, dass die Nachricht am Ende die fachliche Änderung beschreibt. Das klingt nach Kosmetik. Es ist der Unterschied zwischen einer Historie, die bei der Fehlersuche hilft, und einer, die nur Platz belegt.

Chat-Verlauf und Commit-Historie

1:40 Fangen wir mit einer Unterscheidung an, die zu Beginn banal klingt und sich später rächt, wenn man sie ignoriert hat: Was Sie mit dem Agenten besprechen, und was am Ende im Repository steht, sind zwei verschiedene Dinge. Denken Sie an ein Gespräch mit einem Handwerker. Im Gespräch fällt alles Mögliche: warum diese Lösung und nicht jene, was Sie ausdrücklich nicht wollten, welcher Kompromiss am Ende stand.

2:03 In der Rechnung steht davon nichts — dort steht, was verbaut wurde. Der Chat-Verlauf ist das Gespräch, der Commit die Rechnung. Beide haben ihre Berechtigung, aber nur eines von beiden bleibt. Der Chat endet mit der Sitzung, oft schon mit dem Schließen des Fensters. Was Sie dort an Begründung zurücklassen, ist eine Woche später niemandem mehr zugänglich — auch Ihnen nicht.

2:25 Es liegt nahe, den Prompt einfach zur Commit-Nachricht zu machen. Es funktioniert nur leider nicht. Ein Prompt beschreibt eine Absicht, kein Ergebnis: Er nennt selten Dateien, oft nicht einmal den betroffenen Bereich. Die eigentlich wertvolle Information — warum der Agent einen bestimmten Weg gewählt hat — steht gar nicht im Prompt, sondern in seiner Zwischenargumentation.

2:47 Und alles, was Sie unterwegs nachgeschoben haben, weil der erste Versuch daneben lag, fehlt sowieso. Was der Agent beim Committen daraus macht, ist eine Zusammenfassung nach seinem Ermessen. Meistens brauchbar. Manchmal genau um das gekürzt, was Sie später gebraucht hätten. Der interessanteste Unterschied in dieser Gegenüberstellung ist der letzte: Sichtbarkeit. Ihr Chat-Verlauf ist Ihr Chat-Verlauf.

3:11 Kollegen sehen ihn nicht, die Kollegin in zwei Jahren erst recht nicht. Alles, was Sie an Wissen dort belassen, ist faktisch privat — selbst wenn es das Werkzeug speichert. Die Commit-Historie ist das Gegenteil: Sie ist geteilt, dauerhaft und durchsuchbar. Daraus folgt eine einfache Arbeitsregel. Alles, was ein anderer Mensch später brauchen könnte, gehört in den Commit. Der Chat darf flüchtig sein — er ist der Notizzettel, nicht das Protokoll.

3:39 Sieben Commits, und fünf davon sagen im Kern dasselbe. Das ist keine Karikatur, das ist ein typischer Ausschnitt. Und jetzt stellen Sie sich vor, Sie suchen einen Fehler, von dem Sie nur wissen, dass er irgendwo hier drin steckt. Woran wollen Sie sich orientieren? Die Nachrichten unterscheiden nichts, die Zeitstempel liegen Minuten auseinander, alle betreffen dasselbe Feature.

4:01 Genau das ist der Punkt, an dem viele anfangen, sich durch Diffs zu klicken. Es gibt einen besseren Weg, und den sehen wir uns im nächsten Kapitel an. Eine kleine Übung, die erstaunlich viel zeigt. Nehmen Sie eine Änderung, die Sie selbst mit KI gebaut haben, und legen Sie zwei Dinge nebeneinander: Ihren Prompt und die Commit-Nachricht, die dabei herauskam.

4:22 Suchen Sie dann drei Informationen, die in beidem fehlen. Erfahrungsgemäß sind es immer dieselben Kandidaten — der Grund für den gewählten Ansatz, die Alternative, die verworfen wurde, und der Hinweis darauf, was bewusst nicht umgesetzt wurde. Genau diese drei Dinge sind es, nach denen später jemand sucht. Und genau sie stehen in keinem der beiden Texte.

4:44 Vier Fehler, die sich fast von selbst einschleichen. Den Prompt wörtlich als Commit-Nachricht übernehmen — bequem, aber es dokumentiert eine Absicht statt einer Änderung. Annehmen, jeder Agent lege ohnehin für jeden Prompt einen Commit an; das tun nur wenige, und wenn, dann nicht immer dort, wo Sie es erwarten. Sich darauf verlassen, dass der Chat später noch abrufbar ist. Und der teuerste: generierte Commit-Nachrichten ungelesen bestätigen.

5:10 Das dauert zehn Sekunden und ist die billigste Qualitätssicherung, die dieses Seminar zu bieten hat.

Fehlerhafte Commits finden

5:17 Kommen wir zum ersten handfesten Werkzeug. Ein Fehler steckt irgendwo in einer Reihe von Commits, und niemand weiß, in welchem. Git kann diese Frage systematisch beantworten — mit einem Verfahren, das viele kennen, aber wenige nutzen. bisect ist eine binäre Suche über Ihre Historie, und das Prinzip kennen Sie aus dem Alltag.

5:37 Wenn in einer Wohnung der Strom ausfällt, prüfen Sie nicht jede Steckdose einzeln — Sie schalten Sicherungen gruppenweise und halbieren mit jedem Schritt den Suchraum. Genau das tut bisect. Sie benennen einen Stand, der noch in Ordnung war, und einen, der es nicht mehr ist. Git checkt den mittleren Commit aus, Sie fällen ein Urteil, und die Hälfte der Kandidaten fällt weg. Aus sieben Commits werden drei Prüfungen. Aus siebzig werden sieben.

6:04 Bei sieben Commits ist Handarbeit noch vertretbar. Man sieht sich die geänderten Dateien an, findet die Stelle, fertig. Das Problem ist, dass diese Zahl nicht stabil bleibt. Ein Agent, der einen Nachmittag lang an einem Feature arbeitet, produziert schnell dreißig oder fünfzig Commits — mit Nachrichten, die keine Unterscheidung erlauben.

6:24 Hinzu kommt, dass ein Fehler sich weiterträgt: Er wurde einmal eingeführt und ist danach in jedem Commit vorhanden, was die Spur verwischt. Der mathematische Vorteil ist deutlich. Statt jeden Commit einmal anzusehen, sehen Sie den Logarithmus davon an. Bei fünfzig Commits sind das sechs Prüfungen. Der Ablauf ist ein Dialog, und man sollte ihn auch so verstehen. Sie eröffnen die Suche, benennen einen guten und einen schlechten Stand, und ab da fragt Git.

6:51 Es checkt einen Commit aus und will von Ihnen eine Einschätzung: gut oder schlecht. Ihre Antwort halbiert den Suchraum, und das wiederholt sich, bis nur noch einer übrig ist. Wichtig ist der letzte Schritt, den viele vergessen: Am Ende steht der Reset. Ohne ihn bleiben Sie auf einem losen HEAD stehen und wundern sich später, warum Ihr Branch verschwunden scheint. Er ist es nicht — Sie stehen nur nicht drauf.

7:15 So sieht eine vollständige Sitzung aus, und beachten Sie, wie wenig Sie eigentlich tun. Zwei Angaben am Anfang, dann drei Urteile — und Git nennt den Übeltäter. Worauf es ankommt, ist die Qualität dieser Urteile. Sie müssen vorher wissen, woran Sie "schlecht" erkennen. Im Beispiel ist es eine Datei mit fest verdrahteten Pfaden, das ist eindeutig.

7:36 Wenn Ihr Kriterium dagegen "fühlt sich langsam an" lautet, wird die Suche unzuverlässig, weil Sie in der Mitte anfangen zu raten. Ein Nachsatz: Wenn sich das Kriterium als Skript formulieren lässt, kann bisect die Prüfung sogar selbst durchlaufen. Probieren Sie es an einem eigenen Repository. Suchen Sie sich einen Fehler, von dem Sie wissen, dass er irgendwann eingeführt wurde, und lassen Sie bisect ihn finden.

8:01 Das Entscheidende steht im Hinweis: Notieren Sie vor dem Start, woran Sie gut und schlecht erkennen. Wer das erst während der Suche festlegt, verschiebt unbewusst die Kriterien und landet beim falschen Commit. Und vergessen Sie den Reset nicht. Erfolgreich ist die Übung, wenn am Ende genau ein Commit benannt ist und Ihr Arbeitsverzeichnis wieder dort steht, wo es vorher war.

8:23 Vier Fallen, und die erste ist die verbreitetste: good und bad vertauschen. Die Suche läuft dann fröhlich in die falsche Richtung und liefert ein Ergebnis, das plausibel aussieht und falsch ist. Die zweite ist subtiler — einen zu späten Commit als gut markieren und damit den Übeltäter aus dem Suchraum ausschließen; im Zweifel lieber weiter zurückgehen.

8:43 Die dritte: unversionierte Änderungen im Arbeitsverzeichnis, die bei jedem Auschecken mitwandern und das Urteil verfälschen. Und die vierte: den Reset vergessen. Der kostet keine Daten, aber einige Minuten Verwirrung.

Fehlerhafte Commits korrigieren

8:57 Wir wissen jetzt, welcher Commit den Fehler eingeführt hat. Bleibt die Frage, was wir damit machen. Und die hat zwei Antworten, zwischen denen man bewusst wählen sollte — nicht nach Geschmack, sondern nach einem sehr konkreten Kriterium. Zwei Wege stehen offen. Der erste: ein neuer Commit obendrauf, der das Problem behebt. Die Historie bleibt, wie sie ist, und wächst um einen Eintrag.

9:21 Der zweite: den ursprünglichen Commit selbst ändern, per interaktivem Rebase. Das Ergebnis sieht aus, als wäre der Fehler nie passiert. Verlockend — aber es hat einen Preis. Sie schreiben Historie neu, und zwar auch die Commits danach, weil deren Kennungen sich ändern. Für Sie allein ist das folgenlos. Für alle, die diesen Stand schon haben, ist es ein Bruch.

9:45 Die Entscheidung hängt an einer einzigen Frage, und die steht in der ersten Zeile: Ist der Commit schon gepusht? Wenn ja, lassen Sie ihn in Ruhe und legen Sie einen neuen obendrauf. Alles andere zwingt Ihre Kollegen zu Aufräumarbeiten, von denen sie nichts ahnen. Wenn nein, steht Ihnen das Rebase offen, und dann sprechen die weiteren Zeilen dafür — besonders, wenn seit dem Fehler viele Commits entstanden sind.

10:09 Alles andere in dieser Tabelle sind Nuancen. Die Push-Frage ist die Entscheidung. Der Ablauf hat etwas von einer Zeitreise mit Rückfahrkarte. Sie starten das Rebase ab dem Vorgänger des fehlerhaften Commits — nicht ab dem Commit selbst, das ist der häufigste Anfängerfehler. Im Editor markieren Sie den betreffenden Eintrag zum Bearbeiten. Git versetzt Sie daraufhin genau in diesen Moment der Geschichte zurück.

10:33 Dort korrigieren Sie den Code, gern wieder mit dem Agenten, und übernehmen die Änderung mit amend in den bestehenden Commit. Ein continue bringt Sie zurück in die Gegenwart. Der schöne Nebeneffekt: Alle Commits danach tragen die Korrektur automatisch mit. Fünf Zeilen für einen Eingriff, der ziemlich mächtig ist. Worauf es ankommt, ist die erste: die Kennung des Vorgängers.

10:55 Ich nehme dafür gern den letzten Commit, von dem ich sicher weiß, dass er sauber war — den hat mir bisect ja gerade geliefert. Das amend ist die eigentliche Magie: Es ersetzt den Commit, statt einen neuen anzulegen. Und ein praktischer Rat, bevor Sie das erste Mal loslegen: Setzen Sie vorher einen Sicherungs-Branch auf den aktuellen Stand.

11:15 Ein misslungenes Rebase lässt sich sonst nur über das Reflog zurückholen, und das will man nicht unter Zeitdruck lernen. Jetzt zusammen: Suchen Sie mit bisect den Commit, in dem eine fest verdrahtete Zeichenkette aufgetaucht ist, und entfernen Sie sie dort, wo sie entstanden ist — nicht mit einem Pflaster obendrauf. Erfolgreich ist die Übung, wenn danach dreierlei gilt: Der Code läuft, die Zeichenkette ist auch in den nachfolgenden Commits verschwunden, und die Historie hat genauso viele Einträge wie vorher.

11:45 Der letzte Punkt ist der Prüfstein. Wenn ein Commit dazugekommen ist, haben Sie den anderen Weg gewählt — auch legitim, aber eben nicht diese Übung. Vier Warnungen, und die erste wiegt am schwersten: gepushte Commits umschreiben, ohne das Team zu informieren. Technisch geht das, sozial ist es teuer. Die zweite ist der schon erwähnte Klassiker — beim Rebase den Commit selbst angeben statt seinen Vorgänger; dann steht der zu ändernde Eintrag gar nicht in der Liste.

12:12 Die dritte: mitten im Rebase einen Konflikt mit einem neuen Commit lösen statt mit amend, wodurch genau das entsteht, was man vermeiden wollte. Und die vierte: einen Agenten frei im Repository arbeiten lassen, während ein Rebase läuft. Das endet selten gut.

Commits verdichten

12:28 Der Fehler ist behoben, die Historie ist korrekt — aber sie ist immer noch unübersichtlich. Fünf Einträge sagen weiterhin dasselbe. Im letzten Kapitel dieses Moduls machen wir daraus einen, der etwas aussagt. Verdichten, meist Squash genannt, fasst mehrere Commits zu einem zusammen. Der Gedanke dahinter ist eine Frage der Perspektive.

12:49 Während der Arbeit folgt ein Commit dem Arbeitsrhythmus — ein Zwischenstand, ein Versuch, eine Korrektur. Beim Lesen später interessiert das niemanden. Da will man eine abgeschlossene fachliche Änderung sehen. Ein Squash übersetzt also von der einen Sicht in die andere. Und weil Agenten in sehr kleinen Schritten arbeiten, ist der Abstand zwischen beiden Sichten größer geworden — was das Verdichten von einer Stilfrage zu einer Notwendigkeit macht.

13:16 Drei Wege, und die Wahl richtet sich nach zwei Fragen. Erstens: Wollen Sie alles zusammenfassen oder nur einen Teil? Zweitens: Ist der Stand schon auf dem Server? Wenn Sie nur einen Teil verdichten wollen und lokal arbeiten, ist das interaktive Rebase das Mittel der Wahl — es ist das einzige, das Sie pro Commit entscheiden lässt.

13:35 Reset und neuer Commit ist der Holzhammer: schnell, aber alle Nachrichten sind weg. Und der Squash im Pull Request ist der eleganteste Weg, wenn schon gepusht wurde — die Einzelschritte bleiben im Quellbranch erhalten, der Zielbranch bekommt einen sauberen Eintrag. Der Ablauf ähnelt dem Rebase von vorhin, nur mit anderen Befehlen in der Liste. Sie starten interaktiv, diesmal bequem über eine Anzahl statt über eine Kennung.

14:00 Der erste Commit in der Liste bleibt auf pick — er ist das Gefäß, das die anderen aufnimmt. Alle weiteren bekommen squash oder fixup. Der Unterschied ist einfach zu merken: squash nimmt die alte Nachricht mit in den Editor, fixup wirft sie weg. Ich nehme meist squash, auch wenn ich am Ende fast alles lösche — man sieht dann wenigstens, was man wegwirft.

14:22 Das ist die Editor-Ansicht, in der die eigentliche Entscheidung fällt. Beachten Sie die Reihenfolge: Git listet hier von alt nach neu, also genau andersherum als im Log. Der oberste Eintrag ist der älteste, und er trägt das pick. Wer das übersieht, verdichtet in die falsche Richtung. Danach öffnet sich ein zweiter Editor für die gemeinsame Nachricht, und dort liegt die eigentliche Arbeit.

14:46 Aus fünf Zeilen "Konfiguration angepasst" wird jetzt ein Satz, der sagt, was das Feature tut. Nehmen Sie sich dafür die zwei Minuten — es ist der einzige Teil, den später jemand liest. Zum Abschluss die Königsdisziplin: Machen Sie aus einer Serie gleichförmiger Commits einen einzigen, dessen Nachricht auch ohne Kenntnis der Sitzung verständlich ist.

15:08 Der Erfolgstest ist streng, aber fair — geben Sie die Nachricht jemandem, der nicht dabei war. Wenn diese Person sagen kann, was sich fachlich geändert hat, sind Sie fertig. Der Hinweis ist die halbe Miete: eine Zeile Zusammenfassung, darunter das Warum. Nicht die Liste der geänderten Dateien — die steht im Diff und wird von Git ohnehin mitgeliefert.

15:29 Vier Punkte zum Schluss. Zu weit verdichten: Wenn Sie zwei fachlich getrennte Änderungen in einen Commit pressen, haben Sie das Problem nur umgedreht — jetzt lässt sich nichts mehr einzeln zurücknehmen. fixup wählen und dabei die einzige brauchbare Nachricht verwerfen; das passiert schneller, als man denkt. Commits verdichten, die andere schon ausgecheckt haben — dieselbe Regel wie beim Rebase. Und der letzte, fast schon poetisch: die neue Nachricht wieder aus dem Prompt kopieren.

15:57 Damit wären wir am Anfang dieses Moduls angekommen.

Modul 2 geschafft

16:00 Halten wir fest: bisect findet den fehlerhaften Commit in wenigen Prüfungen, statt Sie durch Diffs klicken zu lassen. Das interaktive Rebase korrigiert ihn dort, wo er entstanden ist, statt ihn zu überdecken. Und der Squash übersetzt den Arbeitsrhythmus des Agenten in eine Historie, die ein Mensch lesen kann. Alle drei Werkzeuge gab es lange vor der KI — sie sind nur wichtiger geworden.

16:23 Im nächsten Modul lassen wir nicht mehr einen Agenten arbeiten, sondern zwei gleichzeitig. Und stoßen damit auf ein Problem, das Git ebenfalls schon gelöst hat.