Git, Sessions und parallele Arbeit

Git, Sessions und parallele Arbeit

0:00 Versionskontrolle gehört zu den Dingen, die man für selbstverständlich hält. Beim Arbeiten mit einem Agenten ändert sich ihre Rolle: Sie ist nicht mehr nur Historie, sondern das Sicherheitsnetz, das mutiges Delegieren überhaupt erst erlaubt. Wer weiß, dass er jederzeit zurückkann, gibt größere Aufträge und prüft entspannter.

0:18 In diesem Modul geht es um dieses Netz — um Commits als Kontrollpunkte, um den geordneten Rückweg, um Sessions, die man verzweigen kann, und um Worktrees, mit denen mehrere Agenten gleichzeitig arbeiten, ohne sich in die Quere zu kommen.

Git, Sessions und parallele Arbeit

0:33 Acht Kapitel, die eine gemeinsame Botschaft tragen: Der Commit vor dem Lauf ist wichtiger als jede Einstellung im Werkzeug. Wir beginnen bei der Kombination aus Agent und Versionskontrolle, sehen uns an, wie man Änderungen nachvollzieht und rückgängig macht, wie Sessions organisiert und verzweigt werden, und enden bei der Frage, wie viel Parallelität ein Mensch überhaupt sinnvoll betreuen kann.

0:54 Die Antwort auf die letzte Frage wird manche überraschen.

Codex mit Versionskontrolle kombinieren

0:57 Beginnen wir mit der Grundlage. Git kennen Sie, aber im Zusammenspiel mit einem Agenten bekommt es eine zusätzliche Bedeutung, die über Historie und Zusammenarbeit hinausgeht. Sehen wir uns an, welche das ist, welche Gewohnheiten daraus folgen und warum ausgerechnet der banalste dieser Schritte am häufigsten übersprungen wird.

1:16 Git ist beim agentischen Arbeiten mehr als Historie: Es macht jeden Zwischenstand rückholbar, jede Änderung sichtbar und jeden Vergleich möglich. Ohne saubere Commits ist eine Agentensitzung nicht rekonstruierbar. Das ist der wesentliche Punkt. Bei eigener Arbeit erinnern Sie sich, was Sie geändert haben — bei Agentenarbeit nicht, denn Sie haben es nicht getippt.

1:37 Der Commit ist dann die einzige verlässliche Aufzeichnung dessen, was tatsächlich geschehen ist. Der Chatverlauf ist es nicht; er wird verdichtet und verschwindet. Vier Punkte. Ein sauberer Ausgangszustand macht jedes Diff aussagekräftig — wenn schon Ihre eigenen Änderungen im Arbeitsverzeichnis liegen, wissen Sie hinterher nicht, was vom Agenten stammt.

1:58 Jeder Zwischenstand ist einzeln rückholbar. Nach dem Verdichten bleibt der Stand im Commit belegt, auch wenn der Agent sich nicht mehr erinnert. Und parallele Arbeit wird über Branches überhaupt erst möglich — darauf kommen wir später im Modul ausführlich zurück. Fünf Gewohnheiten. Mit sauberem Arbeitsverzeichnis starten. Für die Aufgabe einen eigenen Branch anlegen. Nach jedem Teilschritt committen.

2:22 Die Commit-Nachricht selbst prüfen und schärfen — sie ist Ihre Aussage, nicht die des Agenten. Und erst nach eigener Durchsicht pushen. Die Fußzeile hebt den ersten Schritt hervor, weil er so banal klingt: Vermischte Änderungen sind der häufigste Grund für unlesbare Diffs. Zwei Minuten Aufräumen vorher sparen eine halbe Stunde Rätselraten nachher.

2:43 Der erste Punkt ist der häufigste: eigene und Agentenänderungen im selben Commit. Danach lässt sich nicht mehr trennen, wer was verantwortet. Der zweite ist eine Grundregel, die aber unter Zeitdruck fällt: nicht direkt auf dem Hauptbranch arbeiten. Der dritte betrifft die Commit-Nachrichten — ungelesen übernommen, beschreiben sie manchmal etwas anderes, als tatsächlich passiert ist.

3:05 Und der vierte ist die Sammelfalle: Ein großer Commit am Ende der Session macht die ganze Arbeit unteilbar.

Änderungen sicher nachvollziehen

3:12 Jetzt zum Handwerk des Nachvollziehens. Der Agent schreibt Ihnen am Ende eine Zusammenfassung dessen, was er getan hat — freundlich, strukturiert und überzeugend. Die Frage ist, ob sie vollständig ist. Sehen wir uns an, mit welchen Handgriffen Sie das prüfen und worauf sich der Blick dabei besonders lohnt. Nachvollziehen heißt, das tatsächliche Diff gegen den erteilten Auftrag zu halten.

3:36 Der Bericht des Agenten ist eine Zusammenfassung, keine Quelle — Quelle ist allein der Unterschied im Arbeitsverzeichnis. Das ist keine Unterstellung gegenüber dem Modell. Eine Zusammenfassung lässt naturgemäß weg, und was sie weglässt, entscheidet sie selbst. Wenn nebenbei eine Konfigurationsdatei angepasst wurde, weil es notwendig schien, steht das im Bericht vielleicht nicht — im Diff steht es garantiert.

4:00 Vier Blickwinkel auf dieselbe Sache. Die Ansicht im Agenten zeigt die Änderungen einschließlich neuer Dateien — und das ist wichtig, denn neue Dateien tauchen im gewöhnlichen Git-Diff nicht auf, solange sie nicht hinzugefügt wurden. Der Statusbefehl gibt den Überblick, die Statistik zeigt den Umfang je Datei, und mit dem letzten Befehl übernehmen Sie bewusst einzeln.

4:20 Gerade der letzte lohnt sich bei Agentenarbeit mehr als bei eigener: Er zwingt Sie, jede Änderung einmal anzusehen, bevor sie im Commit landet. Vier Muster. Neue Dateien, die niemand verlangt hat — das ist das schnellste Warnsignal überhaupt, weil es sich in der Dateiliste zeigt und keine Inhaltsprüfung braucht. Änderungen in Konfiguration und Abhängigkeiten; dort wirken Änderungen weit über die aktuelle Aufgabe hinaus.

4:46 Entfernte Prüfungen, Sonderfälle oder Tests — Dinge, die im Weg standen. Und Formatierungsrauschen, das die Sicht verstellt und dazu führt, dass man das Wesentliche überliest. Diese Übung hat ein klares Kriterium: Jede Änderung im Diff muss einer Zeile des Auftrags zuzuordnen sein. Alles, was übrig bleibt, ist eine bewusste Entscheidung — entweder Sie nehmen es, weil es sinnvoll ist, oder Sie verwerfen es.

5:10 Der Hinweis nennt die Reihenfolge, die am schnellsten zum Ziel führt: Fangen Sie bei der Dateiliste an. Überraschende Dateien erkennen Sie in Sekunden, und sie sind der zuverlässigste Hinweis darauf, dass der Auftrag anders verstanden wurde als gemeint.

Arbeitsschritte rückgängig machen

5:25 Kommen wir zu dem Teil, der agentisches Arbeiten überhaupt erst entspannt macht: dem Weg zurück. Wer ihn kennt und geübt hat, kann größere Aufträge wagen, weil ein Fehlschlag nichts kostet außer Zeit. Sehen wir uns die Werkzeuge an, nach Härte sortiert — und die Fallstricke, die dabei gern übersehen werden. Ein fehlgeschlagener Agentenlauf ist kein Schaden, solange der Weg zurück bekannt ist. Genau deshalb ist der Commit vor dem Lauf wichtiger als jede Einstellung im Werkzeug.

5:54 Das ist die zentrale Aussage dieses Moduls, und sie hat eine praktische Konsequenz: Wer sich Gedanken über Berechtigungen und Sandboxen macht, aber ohne Commit arbeitet, sichert an der falschen Stelle ab. Die Sandbox schützt Ihren Rechner. Der Commit schützt Ihre Arbeit. Vier Wege, nach Härte sortiert. Eine einzelne Datei verwerfen. Alle Änderungen verwerfen. Auf den letzten Commit zurücksetzen.

6:18 Und einen bereits committeten Stand zurücknehmen, wobei die Historie erhalten bleibt. Der letzte ist der, den Sie auf geteilten Branches brauchen — dort darf die Historie nicht umgeschrieben werden, weil andere darauf aufbauen. Die Fußzeile nennt die beruhigende Grenze: Verwerfen betrifft nur Ungespeichertes. Was committet ist, bleibt erhalten, egal wie oft Sie verwerfen.

6:42 Der erste Punkt ist der schmerzhafteste: Verworfen wird auch, was Sie selbst geschrieben haben. Das Verwerfen kennt keinen Unterschied zwischen Agentenarbeit und Ihrer. Der zweite ist die Voraussetzung für alles: Ohne Commit vor dem Lauf hilft kein Rücksprung. Der dritte ist ein technisches Detail, das überrascht: Neue, noch nicht getrackte Dateien bleiben beim Verwerfen liegen.

7:04 Und der vierte ist eine Teamregel: Auf geteilten Branches ist das Umschreiben der Historie tabu. Diese Übung ist bewusst prophylaktisch: Sie sollen den Rückweg beherrschen, bevor Sie ihn brauchen. Denn im Ernstfall ist genau die Ruhe weg, die man dafür braucht. Verunglücken Sie einen Lauf absichtlich und nehmen Sie ihn vollständig zurück. Der Hinweis ist ernst gemeint: Üben Sie das an einem Wegwerf-Branch.

7:28 Es wäre eine unschöne Ironie, wenn ausgerechnet die Übung zum Rückgängigmachen echte Arbeit kostet.

Sessions organisieren

7:35 Wir haben Sessions bereits in Modul eins kennengelernt. Jetzt geht es um die Ordnung darin — und die ist wichtiger, als sie klingt. Denn die häufigste Ursache für schwächer werdende Antworten ist kein Modellproblem, sondern eine Session, in der zu viel gleichzeitig steckt. Sehen wir uns an, wie man das vermeidet. Eine Session bündelt Auftrag, gelesene Dateien und Verlauf. Sie wird je Arbeitsverzeichnis gespeichert und lässt sich später fortsetzen.

8:02 Ihr Wert steht und fällt damit, dass sie thematisch geschlossen bleibt. Das Bild vom Schreibtisch trägt hier weiter: Solange ein Vorgang ausgebreitet liegt, finden Sie alles. Sobald drei Vorgänge übereinanderliegen, greifen Sie ins falsche Papier. Beim Agenten äußert sich das darin, dass er Zusammenhänge herstellt, die es gar nicht gibt.

8:22 Vier Befehle für den Alltag. Eine neue Session starten, eine gespeicherte fortsetzen, innerhalb der Sitzung ein neues Thema beginnen und den Verlauf zurücksetzen. Die beiden letzten sind die, die man sich angewöhnen sollte — sie kosten nichts und halten den Kontext sauber. Die Fußzeile enthält ein Detail, das später im Modul wichtig wird: Sessions hängen am Arbeitsverzeichnis.

8:44 Wenn Sie gleich mit Worktrees arbeiten, beginnt in jedem Verzeichnis eine eigene Ablage — das ist Absicht und meistens genau richtig. Vier Gründe. Vermischter Kontext führt zu vermischten Ergebnissen — der Agent zieht Schlüsse aus Dateien, die zu Ihrer aktuellen Frage nicht gehören. Ein langer Verlauf wird verdichtet und verliert dabei Details. Getrennte Sessions lassen sich einzeln fortsetzen, was bei mehrtägigen Aufgaben Gold wert ist.

9:10 Und der Bezug zwischen Auftrag und Diff bleibt erkennbar. Der letzte Punkt zahlt direkt auf das Prüfen ein: Wenn eine Session ein Thema hat, wissen Sie beim Review, wonach Sie suchen. Der erste Punkt ist der Klassiker: das zweite Thema im laufenden Verlauf anhängen, weil das Fenster ja schon offen ist. Der zweite betrifft Sessions, die ewig offen bleiben, statt abgeschlossen zu werden.

9:33 Der dritte beschreibt eine passive Haltung — aufs automatische Verdichten warten, statt selbst zu ordnen. Und der vierte ist der folgenreichste: Ergebnisse nur im Verlauf sichern statt in Dateien. Alles, was nur im Chat steht, überlebt weder das Verdichten noch das Schließen der Session.

Sessions verzweigen

9:50 Jetzt zu einer Funktion, die viele gar nicht kennen und die erstaunlich nützlich ist: das Verzweigen einer Session. Sie können aus dem aktuellen Gesprächsstand einen zweiten Strang erzeugen und darin etwas anderes ausprobieren, ohne den ersten zu verlieren. Sehen wir uns an, welche Varianten es gibt und wofür sich das im Alltag lohnt.

10:09 Verzweigen heißt, aus dem aktuellen Gesprächsstand einen zweiten Strang zu erzeugen. Der Ursprung bleibt unberührt, der Zweig geht eigene Wege — für einen zweiten Lösungsansatz oder eine Zwischenfrage. Das Prinzip kennen Sie von Git- Branches, nur geht es hier um den Gesprächskontext statt um Dateien. Und der Nutzen ist derselbe: Sie können etwas Riskantes probieren, ohne den erarbeiteten Stand zu gefährden. Der ist oft wertvoller als der Code, der bisher entstanden ist.

10:37 Zwei Varianten mit unterschiedlicher Lebensdauer. Der dauerhafte Abzweig wird als eigene Session gespeichert und lässt sich später wieder aufnehmen — das ist der Weg für einen echten zweiten Lösungsansatz, den Sie vielleicht morgen weiterführen. Die Nebenfrage ist kurzlebig und wird nicht gespeichert; sie ist für die schnelle Zwischenfrage gedacht, die Sie nicht in den Hauptverlauf tragen wollen.

10:58 Die Wahl richtet sich schlicht danach, ob Sie das Ergebnis später noch brauchen. Vier Anwendungsfälle. Zwei Ansätze am selben Ausgangspunkt vergleichen — und weil der Ausgangspunkt derselbe ist, ist der Vergleich fair. Eine Zwischenfrage stellen, ohne den Kontext zu stören. Einen riskanten Weg ausprobieren und notfalls fallen lassen.

11:18 Und den erarbeiteten Kontext mehrfach nutzen, statt ihn neu aufzubauen. Der letzte Punkt ist der wirtschaftlichste: Der Kontext hat Zeit und Rechenleistung gekostet. Ihn zweimal zu verwenden ist schlicht sparsamer. Bei dieser Übung geht es um Fairness im Vergleich. Der Hinweis ist der Kern: Verzweigen Sie, statt zwei Sessions neu aufzusetzen.

11:40 Nur dann haben beide Ansätze denselben Ausgangspunkt und dieselbe Vorarbeit — und nur dann sagt der Vergleich etwas über die Ansätze aus statt über Zufälle beim Kontextaufbau. Dokumentieren Sie die Entscheidung schriftlich. Diese Begründung ist genau das, was später im Review oder in der Spezifikation fehlt.

Worktrees für parallele Arbeit

11:58 Jetzt zum vielleicht praktischsten Werkzeug dieses Moduls. Wenn zwei Agenten gleichzeitig arbeiten sollen, brauchen sie getrennte Arbeitsverzeichnisse — sonst schreiben sie in dieselben Dateien. Git hat dafür seit langem eine Lösung, die viele nie gebraucht haben. Sehen wir uns an, wie Worktrees funktionieren und worauf man dabei achten muss.

12:19 Ein Worktree ist ein zusätzliches Arbeitsverzeichnis desselben Repositorys mit eigenem Branch. Zwei Agenten können so gleichzeitig arbeiten, ohne sich in denselben Dateien zu begegnen. Das Bild dazu: derselbe Aktenschrank, aber zwei Schreibtische. Die Historie ist gemeinsam, der aktuelle Stand ist getrennt. Sie müssen also nicht das Repository doppelt klonen — und Sie müssen auch nicht ständig den Branch wechseln und dabei Zwischenstände wegräumen.

12:46 Vier Handgriffe. Sie legen für jede Aufgabe ein eigenes Verzeichnis mit eigenem Branch an, starten dort jeweils eine eigene Codex-Session, behalten mit der Auflistung den Überblick und räumen am Ende wieder auf. Wichtig ist der letzte Punkt: Aufgeräumt wird über den Git-Befehl, nicht durch Löschen des Verzeichnisses — sonst bleibt Git in einem inkonsistenten Zustand zurück.

13:07 Die Fußzeile fasst das Prinzip: eigener Stand, eigene Sessions, gemeinsame Historie. Vier Probleme auf einmal. Keine Konflikte in denselben Dateien — das ist der Hauptgrund. Jede Aufgabe auf ihrem eigenen Branch. Je Aufgabe ein eigenes, prüfbares Diff. Und Wechseln ohne Zwischenstände wegzuräumen. Der letzte Punkt ist im Alltag der angenehmste: Sie können von der einen Aufgabe zur anderen gehen, indem Sie das Terminal wechseln — kein Stashen, kein Committen von Halbfertigem, kein Nachdenken darüber, in welchem Zustand Sie das andere Thema verlassen haben.

13:42 Der erste Punkt kostet beim ersten Mal Nerven: Abhängigkeiten müssen je Worktree installiert werden — jedes Verzeichnis braucht seine eigenen Pakete. Der zweite ist im Alltag noch lästiger: Lokale Dienste und Ports kollidieren schnell, wenn zwei Instanzen derselben Anwendung starten wollen. Der dritte ist die schon erwähnte Aufräumregel.

14:01 Und der vierte ist eine Selbstverständlichkeit mit Tücke: Nicht committete Arbeit bleibt im jeweiligen Worktree — und wird dort leicht vergessen.

Aufgaben voneinander isolieren

14:10 Damit sind wir bei der Frage, wie viel Parallelität überhaupt sinnvoll ist. Technisch könnten Sie zehn Agenten gleichzeitig laufen lassen. Praktisch gibt es eine Grenze, und sie liegt niedriger, als die meisten vermuten — sie hat nämlich nichts mit der Maschine zu tun. Sehen wir uns an, wo sie liegt und woran man sie merkt.

14:29 Isolation heißt: getrennter Branch, getrenntes Arbeitsverzeichnis, getrennte Session, getrenntes Review. Der begrenzende Faktor ist nicht die Maschine, sondern die Aufmerksamkeit, die jedes Ergebnis braucht. Das ist der entscheidende Satz. Ein Agent, der zwanzig Minuten arbeitet, produziert ein Ergebnis, das Sie vielleicht zehn Minuten prüfen müssen.

14:50 Bei vier parallelen Aufgaben kommen also alle zwanzig Minuten vierzig Minuten Prüfarbeit an. Die Rechnung geht nicht auf, und dann stapeln sich ungeprüfte Ergebnisse. Vier Ebenen, jede mit einem eigenen Grund. Der Branch sorgt für ein eigenes, prüfbares Diff. Das Arbeitsverzeichnis verhindert Dateikonflikte. Die Session verhindert vermischten Kontext. Und das Review sorgt dafür, dass je Aufgabe eine Entscheidung fällt statt einer Sammelentscheidung über alles.

15:19 Die Fußzeile nennt die Erfahrungsgrenze: drei bis vier parallele Aufgaben. Darüber wird das Prüfen zum Engpass — und ein Engpass beim Prüfen bedeutet in der Praxis, dass weniger geprüft wird. Vier Anzeichen. Ergebnisse stapeln sich schneller, als sie geprüft werden. Aufgaben berühren dieselben Dateien und kollidieren beim Zusammenführen — deshalb sollte man parallele Aufgaben bewusst in verschiedenen Bereichen wählen.

15:45 Der Überblick über die Zuordnung geht verloren; man weiß nicht mehr, welcher Branch zu welchem Auftrag gehört. Und ein Fehler in einem Strang bleibt lange unbemerkt, weil die Aufmerksamkeit gerade woanders ist. Der Hinweis ist hier der wichtigste Teil: Wählen Sie bewusst zwei Aufgaben in verschiedenen Bereichen. Überlappende Aufgaben zeigen Ihnen den Preis der Parallelität sofort — beim Zusammenführen.

16:09 Beide Branches sollen einzeln prüfbar, einzeln getestet und ohne Konflikte zusammenführbar sein. Und achten Sie darauf, wie sich Ihre eigene Aufmerksamkeit anfühlt, während zwei Läufe gleichzeitig arbeiten. Diese Beobachtung sagt Ihnen mehr über Ihre persönliche Grenze als jede Faustregel.

Agentische Arbeit und Git-Workflows

16:26 Zum Abschluss die Einordnung ins Team. Alles, was wir besprochen haben, findet ja nicht im luftleeren Raum statt — es gibt einen etablierten Ablauf mit Branches, Pull Requests und Reviews. Sehen wir uns an, wie sich Agentenarbeit da einfügt und an welcher Stelle die Versuchung am größten ist, eine Abkürzung zu nehmen. Agentisch erzeugte Änderungen durchlaufen denselben Weg wie jede andere Arbeit: eigener Branch, Pull Request, Review, Tests in der Pipeline.

16:53 Der Unterschied liegt im Tempo, nicht in den Regeln. Genau dieses Tempo ist die Belastungsprobe. Wenn plötzlich dreimal so viele Pull Requests entstehen, gerät ein Review-Prozess unter Druck, der vorher gut funktioniert hat. Die Antwort darauf ist nicht, den Prozess zu umgehen — sondern die Pull Requests kleiner zu schneiden.

17:13 Fünf Schritte, die Ihnen vertraut vorkommen sollten, weil sie Ihr normaler Ablauf sind. Branch je Aufgabe mit dem üblichen Namensschema. Commits je Teilschritt, die Nachricht selbst verantwortet. Pull Request wie gewohnt. Das Review durch den Agenten als Vorstufe, nicht als Ersatz. Und die menschliche Freigabe vor dem Zusammenführen.

17:33 Die Fußzeile nennt eine hilfreiche Gewohnheit: Wer den Agenten in der Commit-Nachricht kenntlich macht, erleichtert die spätere Ursachensuche erheblich. Der erste Punkt ist die große Versuchung: Agentenarbeit am Review vorbeischleusen, weil es ja schnell ging und offensichtlich richtig aussieht. Der zweite betrifft den Umfang — Pull Requests, die ein Tageswerk umfassen, werden nicht geprüft, sondern durchgewinkt.

17:57 Der dritte ist eine klare Grenze: Fremde Commits nicht nachträglich umschreiben lassen. Und der vierte ist die Wiederholung eines Grundsatzes: Eine grüne Pipeline ist kein Ersatz für die Durchsicht. Diese Übung ist zugleich ein Test für Ihren Prozess, nicht nur für Sie. Führen Sie eine agentisch erstellte Änderung vollständig durch Ihren Team-Workflow.

18:18 Und dann achten Sie auf den Hinweis: Bricht Ihr Workflow an irgendeiner Stelle, weil das Tempo ein anderes ist? Genau diese Stelle ist die interessante. Vielleicht ist es die Review-Kapazität, vielleicht die Größe der Pull Requests, vielleicht die Namenskonvention für Branches. Was Sie finden, gehört ins nächste Retro. Vier Punkte zum Mitnehmen. Der Commit vor dem Lauf ist wichtiger als jede Einstellung im Werkzeug — er ist das eigentliche Sicherheitsnetz.

18:45 Quelle ist das Diff, nicht der Bericht des Agenten. Worktrees trennen parallele Aufgaben sauber, und Sessions hängen dabei am Verzeichnis. Und der Engpass beim parallelen Arbeiten ist das Prüfen, nicht das Rechnen. Im nächsten Modul geht es um die technische Seite der Kontrolle: Berechtigungen, Sandbox und die Frage, wie viel Autonomie eine Aufgabe verträgt.