Git Worktrees: Der Parallelmodus für Coding-Agenten

Ein Coding-Agent behebt einen Bug, ein zweiter baut parallel ein Feature und ein dritter untersucht eine alternative Architektur. Wenn alle im selben Ordner arbeiten, verändern sie gegenseitig Dateien, Index und Branch. Git Worktrees geben jedem Agenten einen eigenen Arbeitsbereich – ohne das Repository dreimal vollständig zu klonen.

Worktrees sind keine neue KI-Technologie. Sie gehören zu Git und lösen ein altes Problem: Wie kann ich mehrere Branches desselben Repositorys gleichzeitig ausgecheckt haben? Für Menschen ist das bequem. Für Coding-Agenten wird es zu einer wichtigen Isolationsschicht, weil parallele Aufgaben nicht mehr um denselben Dateisystemzustand konkurrieren.

Ein Git-Repository verzweigt sich in drei isolierte Worktrees für drei parallele Coding-Agenten. — Ein gemeinsames Repository, mehrere isolierte Arbeitsbereiche: Jeder Agent arbeitet auf seinem eigenen Branch, ohne den Checkout der anderen zu überschreiben.

Was ist ein Git Worktree?

Ein normales Git-Repository hat einen Arbeitsbaum: den Ordner mit den ausgecheckten Dateien. Dazu kommen der Index – also die Staging Area – und die Git-Datenbank mit Commits, Branches und Objekten. Mit git worktree kann dasselbe Repository zusätzliche Arbeitsbäume erhalten.

Git unterscheidet dann zwischen dem main worktree und beliebig vielen linked worktrees. Jeder verknüpfte Worktree besitzt ein eigenes Verzeichnis, einen eigenen HEAD und einen eigenen Index. Die großen Git-Objekte und die meisten Referenzen werden gemeinsam genutzt. Deshalb ist ein Worktree schneller und platzsparender als ein weiterer vollständiger Clone.

# Neuen Branch in einem zusätzlichen Arbeitsbereich anlegen
git worktree add -b agent/login-fix ../repo-login-fix main

# Aktive Worktrees anzeigen
git worktree list

# Nach Abschluss sauber entfernen
git worktree remove ../repo-login-fix
git branch -d agent/login-fix

Anatomie von Git Worktrees mit gemeinsamem Git-Repository und getrennten Dateien, HEAD und Index pro Arbeitsbereich. — Geteilt wird die Repository-Basis. Getrennt bleiben die Zustände, die bei paralleler Arbeit sonst sofort kollidieren würden: Dateien, HEAD und Index.

Was wird geteilt – und was nicht?

Gemeinsam: Commits und Git-ObjekteAlle Worktrees sehen dieselbe Objektdatenbank. Ein Commit, den Agent A erzeugt, ist deshalb unmittelbar für Agent B verfügbar, auch bevor etwas zu einem Remote gepusht wurde.

Gemeinsam: Branch-Referenzen und Repository-KonfigurationBranches gehören grundsätzlich zum gemeinsamen Repository. Git verhindert daher standardmäßig, dass derselbe Branch gleichzeitig in zwei Worktrees ausgecheckt wird.

Getrennt: ArbeitsdateienJeder Worktree hat seinen eigenen physischen Projektordner. Änderungen eines Agenten tauchen nicht als uncommitted Änderungen im Verzeichnis eines anderen auf.

Getrennt: HEAD und IndexJeder Agent kann einen anderen Branch ausgecheckt und eine eigene Staging Area haben. Auch Merge-, Rebase- und Bisect-Zustände sind weitgehend worktree-spezifisch.

Diese Trennung ist der eigentliche Wert. Ein Worktree ist nicht nur „noch ein Ordner“. Er ist ein eigener Checkout mit eigenem Arbeitszustand, der trotzdem an dieselbe Repository-Historie angeschlossen bleibt.

Warum Coding-Agenten davon besonders profitieren

Menschen wechseln zwischen Branches und merken, wenn lokale Änderungen im Weg stehen. Coding-Agenten arbeiten autonomer: Sie lesen Dateien, ändern mehrere Komponenten, starten Tests und erzeugen Commits. Laufen zwei Agenten im selben Checkout, kann der eine mitten im Testlauf Dateien verändern, die der andere gerade bewertet. Das Ergebnis wird unzuverlässig, selbst wenn Git am Ende keinen formalen Konflikt meldet.

Ein Worktree gibt jeder Aufgabe eine klare räumliche Grenze. Der Prompt „Behebe Issue 417“ bekommt nicht nur einen Thread und einen Branch, sondern einen eigenen Ordner. Der Agent darf darin bauen, testen und iterieren, ohne den lokalen Zustand anderer Aufgaben anzufassen. OpenAI beschreibt Worktrees deshalb als eingebaute Grundlage dafür, dass mehrere Codex-Agenten parallel am selben Repository arbeiten können.

Workflow für parallele Coding-Agenten von Aufgabe über eigenen Worktree und Tests bis zu Review und Integration. — Parallelität wird kontrollierbar, wenn jede Aufgabe eine eigene Kette aus Branch, Worktree, Tests, Diff und Review erhält. Zusammengeführt wird erst nach der Prüfung.

Worktrees ermöglichen Parallelität, aber keine Magie

Die Dateisystem-Isolation verhindert viele technische Kollisionen. Sie löst aber keine fachlichen Konflikte. Wenn zwei Agenten dieselbe Schnittstelle unterschiedlich verändern, entstehen die Probleme erst beim Merge. Wenn Agent A ein Datenmodell umbaut und Agent B darauf eine Funktion entwickelt, können beide Worktrees einzeln grün sein und gemeinsam trotzdem scheitern.

Auch Prozesse außerhalb von Git bleiben geteilt. Zwei lokale Anwendungen können denselben Port beanspruchen. Testläufe können dieselbe Datenbank verändern. Docker-Container, Cloud-Ressourcen, Caches, globale Paketinstallationen und Secrets werden durch einen Worktree nicht automatisch isoliert. Wer echte Parallelität will, muss zusätzlich eindeutige Ports, Datenbanken, Container-Namen und temporäre Ressourcen vergeben.

Die wichtigste Grenze: Ein Worktree isoliert den Git-Arbeitszustand. Er isoliert nicht automatisch die Laufzeitumgebung und verhindert keine semantischen Merge-Konflikte.

Ein gutes Betriebsmodell für mehrere Agenten

Ich würde nicht für jeden beliebigen Prompt sofort einen neuen Worktree erzeugen. Der Ansatz lohnt sich für Aufgaben, die tatsächlich parallel laufen, einen klaren Scope besitzen und als eigener Diff überprüfbar sind. Ein produktives Muster sieht so aus:

1. Aufgabe schneidenJeder Agent erhält ein überprüfbares Ergebnis, definierte Grenzen und möglichst wenige gemeinsame Hotspots mit anderen laufenden Aufgaben.

2. Branch und Worktree gemeinsam erzeugenDer Name verbindet Aufgabe und Arbeitsbereich, etwa agent/417-login-timeout. Der Ausgangscommit wird festgehalten.

3. Umgebung vorbereitenAbhängigkeiten, lokale Konfiguration, Ports und Testdaten müssen pro Worktree reproduzierbar sein. Generierte Ordner werden nicht blind zwischen Agenten geteilt.

4. Ergebnis als Diff prüfenTests, Linting und Security Checks laufen im Worktree. Der Mensch oder ein Review-Agent bewertet den Diff gegen die Akzeptanzkriterien.

5. Bewusst integrieren und aufräumenErst nach Review wird gemergt oder übernommen. Danach folgen git worktree remove und das Löschen des erledigten Branches.

Typische Stolperstellen

Ein Branch kann normalerweise nur einmal ausgecheckt sein. Das ist ein Schutzmechanismus. Jeder parallele Agent sollte einen eigenen Branch erhalten. --force ist hier selten eine gute Lösung.

Ein Worktree enthält eine .git-Datei statt eines vollständigen .git-Ordners. Werkzeuge sollten Git über normale Befehle abfragen und keine festen Annahmen über das Repository-Layout treffen.

Abhängigkeiten brauchen Platz. Git-Objekte werden geteilt, aber node_modules, Build-Ausgaben oder virtuelle Umgebungen liegen häufig pro Worktree separat. Das kostet Speicher, verhindert dafür aber gefährliche Seiteneffekte.

Gelöschte Ordner hinterlassen Metadaten. Worktrees sollten mit git worktree remove entfernt werden. Nach manuellem Löschen bereinigt git worktree prune veraltete Verwaltungsdaten.

Zu viel Parallelität erhöht Integrationskosten. Zehn Agenten erzeugen nicht automatisch zehnmal so viel Wert. Je stärker Aufgaben dieselben Dateien, Verträge und Architekturentscheidungen berühren, desto mehr Zeit wandert in Review, Rebase und Merge.

Was Worktrees für die Rolle des Entwicklers bedeuten

Mit Coding-Agenten verschiebt sich die Arbeit vom dauernden Tippen hin zur Orchestrierung: Aufgaben schneiden, Ausgangspunkte wählen, Ergebnisse vergleichen und Änderungen integrieren. Worktrees machen diese neue Arbeitsweise technisch greifbar. Jeder Agent bekommt einen kontrollierten Raum, aber nicht automatisch das Recht, seine Lösung in den Hauptbranch zu bringen.

Besonders spannend wird das bei Alternativen. Zwei Agenten können dieselbe Aufgabe bewusst unterschiedlich lösen: einer minimal-invasiv, einer mit architektonischer Bereinigung. Beide Varianten entstehen aus demselben Ausgangscommit in getrennten Worktrees. Der Entwickler vergleicht danach nicht abstrakte Vorschläge, sondern lauffähige Diffs mit Tests.

Mein Fazit

Git Worktrees sind eine kleine Funktion mit großer Wirkung für agentische Softwareentwicklung. Sie machen aus einem Repository mehrere parallele Arbeitsplätze, ohne mehrere unabhängige Git-Welten zu erzeugen. Genau das brauchen Coding-Agenten: isolierte Dateien und Zustände, aber eine gemeinsame Historie für Review und Integration.

Der entscheidende Punkt ist jedoch nicht maximale Parallelität. Es ist kontrollierte Parallelität. Ein Agent pro Worktree verhindert gegenseitiges Überschreiben. Gute Aufgabenschnitte, reproduzierbare Umgebungen, klare Eigentümerschaft und bewusstes Mergen verhindern, dass die Konflikte nur ans Ende verschoben werden. Worktrees sind deshalb kein Ersatz für Engineering-Disziplin. Sie sind die Infrastruktur, mit der diese Disziplin bei mehreren Agenten überhaupt skalieren kann.

Weiterführende Quellen

Git-Dokumentation: git-worktree zu Befehlen, gemeinsamem Repository und worktree-spezifischem Zustand.
Git User Manual zur Definition von Working Tree, Index, HEAD und geteilten Repository-Metadaten.
Git Repository Layout zum Aufbau verknüpfter Worktrees und ihrer Verwaltungsdateien.
OpenAI: Introducing the Codex app zur Nutzung eingebauter Worktrees für parallele Coding-Agenten.

GitGit WorktreesCoding-AgentenKI-CodingCodexParallelisierungSoftwareentwicklung