Git Worktrees für parallele KI-Agenten

Git worktree parallel zu entwickeln ist der sauberste Weg, mehrere Arbeitspakete in einem Repository zu bearbeiten, ohne sie zu vermischen. Mit KI-Agenten zählt das noch mehr: Arbeiten zwei Agenten im selben Ordner, überschreibt einer die Änderungen des anderen, Tests laufen gegen halbfertigen Code und niemand kann sagen, welche Änderung zu wem gehört.

Dieser Beitrag erklärt, was Git Worktrees sind, wie du sie mit Agenten nutzt und wie du jeden Agenten-Turn umkehrbar hältst.

Was ist ein Git Worktree?

Ein Git Worktree öffnet einen anderen Branch desselben Repositories gleichzeitig in einem separaten Ordner. Jeder Ordner hat eigene Arbeitsdateien, aber die .git-Daten sind gemeinsam. Ein Commit in einem Worktree ist sofort aus den anderen sichtbar.

Im Vergleich zu einem Klon:

Grundlegende Befehle

Einen Worktree auf einem neuen Branch erstellen:

git worktree add ../acme-web-auth -b auth-refactor

Einen Worktree von einem bestehenden Branch öffnen:

git worktree add ../acme-web-billing billing-v2

Worktrees auflisten und entfernen:

git worktree list
git worktree remove ../acme-web-auth
git worktree prune

prune räumt Einträge von Worktrees auf, deren Ordner von Hand gelöscht wurden.

Git worktree parallel entwickeln: ein Baum pro Agent

Die Regel für parallele Agenten ist einfach: Gib jedem Agenten mit Konfliktrisiko einen eigenen Worktree.

Ein Beispiel-Layout:

Tester teilt sich den Worktree mit Architect, weil er dessen Änderung testet und nur unter tests/ arbeitet. Der Frontend-Agent arbeitet an etwas ganz anderem, auf einem eigenen Branch.

Das bringt dir:

• Agenten sehen nie die halbfertigen Dateien der anderen.
• Jedes Arbeitspaket wird über einen eigenen Branch und Pull Request gemergt.
• Ein Arbeitspaket zu verwerfen ist so einfach wie das Löschen seines Branches.

Worktrees in AgentVera verwalten

Du kannst Worktrees auf der Kommandozeile verwalten, aber mit wachsender Agentenzahl wird es unübersichtlich. In AgentVera kannst du im Tab „Worktrees“ im rechten Panel:

1. Einen Worktree von einem neuen oder bestehenden Branch erstellen.
2. Die Zahl der Änderungen jedes Worktrees sehen, wie weit er dem Hauptbranch voraus oder hinterher ist, und seinen letzten Commit.
3. Einen Agenten direkt in einem Worktree starten.
4. Einen Worktree sperren, prunen oder erzwungen entfernen und seinen Branch löschen.

Beim Erstellen eines neuen Agenten kannst du außerdem einen Worktree als seinen Workspace wählen, und der Bereich des Agenten zeigt seinen Branch in einem kleinen Tag. Markdown-Dateien, die Agenten in Worktrees ändern, erscheinen im Panel „Specs“ als Pläne und Dokumente.

Jeden Turn umkehrbar halten

Worktrees trennen Agenten voneinander. Aber was, wenn ein Agent innerhalb seines eigenen Worktrees in die falsche Richtung läuft?

Die klassische Antwort ist, oft zu committen, aber jeder Agentenschritt als Commit verstopft die Historie. Die Turns von AgentVera gehen einen anderen Weg:

• Zu Beginn jedes Turns wandert ein Snapshot des Arbeitsordners in eine versteckte Git-Ref.
• Branch, Index und Stash bleiben unberührt.
• Die letzten 60 Turns werden pro Agent behalten.
• Über Turns im Menü Options des Bereichs siehst du die Dateien, die ein Turn geändert hat.
• Undo this turn macht die Änderungen dieses Turns rückgängig, und auch das Rückgängigmachen lässt sich rückgängig machen.

So kannst du einen Agenten frei probieren lassen: Gefällt dir das Ergebnis nicht, bist du einen Klick vom vorherigen Zustand entfernt.

Bevor du mergst

Bevor du fertige Arbeit aus parallelen Branches in den Hauptbranch bringst:

• Führe die Tests in jedem Worktree aus.
• Prüfe die Diffs; das automatische Code-Review beschleunigt das.
• Räume die Commit-Nachrichten auf. Das Git-Panel von AgentVera kann aus dem gestagten Diff mit Claude Haiku eine Nachricht im Stil deines Repos schreiben.
• Pushe den Branch und öffne einen Pull Request; die GitHub-Karte im Git-Panel zeigt den Pull Request des aktuellen Branches oder öffnet einen neuen.

Häufige Fehler

• Denselben Branch in zwei Worktrees öffnen. Git erlaubt es nicht, und das ist eine Schutzmaßnahme.
• Einträge gelöschter Ordner liegen lassen. Räume sie mit git worktree prune auf.
• node_modules vergessen. Jeder Worktree braucht seine eigenen installierten Abhängigkeiten.
• Agenten-Turns wie Commits behandeln. Turns sind zum Rückgängigmachen da; committe trotzdem für eine dauerhafte Historie.

Ein Beispieltag: drei Agenten, zwei Branches

Machen wir das mit einem Arbeitstag konkret.

Morgens: Einrichtung

Im Hauptordner ist main ausgecheckt. Es gibt zwei Aufgaben: einen Auth-Umbau und eine Einstellungsseite. Du öffnest zwei Worktrees:

git worktree add ../acme-web-auth -b auth-refactor
git worktree add ../acme-web-settings -b settings-ui

Installiere in jedem die Abhängigkeiten:

cd ../acme-web-auth && pnpm install
cd ../acme-web-settings && pnpm install

Architect und Tester starten im Worktree auth-refactor; der Frontend-Agent startet in settings-ui.

Mittags: ein Turn geht schief

Beim Bearbeiten der Einstellungsseite ändert der Frontend-Agent auch das Styling einer gemeinsamen Komponente. Das liegt außerhalb seiner Aufgabe. In der Turns-Liste siehst du die Dateien, die der letzte Turn geändert hat, machst den Turn rückgängig und sagst dem Agenten, er solle die gemeinsame Komponente nicht anfassen. Die Branch-Historie bleibt sauber, weil Rückgängigmachen kein Commit ist, sondern die Rückkehr zum Snapshot in der versteckten Ref.

Abends: Mergen

Ist die Auth-Arbeit fertig, führst du die Tests aus, prüfst das Review und pushst den Branch. Ist die Einstellungsseite noch nicht fertig, bleibt ihr Worktree offen, und der Agent macht am nächsten Tag im selben Ordner weiter. Wenn du die App beendest und wieder öffnest, bringt AgentVera Claude- und Codex-Agenten anhand des CLI-Verlaufs zum selben Gespräch zurück.

Umgebungsdetails, auf die du in Worktrees achten solltest

Die häufigsten Stolpersteine bei parallelen Worktrees betreffen die Umgebung, nicht den Code:

• Port-Konflikte: Wenn du in zwei Worktrees gleichzeitig einen Dev-Server startest, lass nicht beide denselben Port anfordern. Gib ihnen über Umgebungsvariablen unterschiedliche Ports.
• Env-Dateien: Dateien, die nicht in Git sind, wie .env, tauchen in einem neuen Worktree nicht von selbst auf; kopiere sie.
• Datenbank: Haben zwei Branches unterschiedliche Migrationen, kann eine gemeinsame lokale Datenbank Probleme machen.

Das Panel „Ports“ von AgentVera zeigt lauschende Ports und welcher Agent sie gestartet hat, sodass du nachvollziehen kannst, welcher Worktree welchen Server geöffnet hat.

Einen Agenten kopieren und das Gespräch forken

Manchmal willst du dasselbe Problem auf zwei Arten angehen. Wenn du in AgentVera einen Agenten kopierst, werden Tool, Account, Modell, Effort, Rolle, Gruppe und Worktree exakt übernommen, und du kannst auch den Gesprächsverlauf forken (--fork-session bei Claude, fork bei Codex).

Zusammen mit Worktrees ergibt das ein starkes Experiment-Setup: Lass zwei vom selben Gespräch geforkte Agenten in zwei Worktrees laufen, vergleiche die Ergebnisse und merge den Branch, der dir gefällt. Den anderen Branch zu löschen räumt das Experiment spurlos auf.

Checkliste

• Hat jeder Agent mit Konfliktrisiko seinen eigenen Worktree?
• Sind in jedem Worktree die Abhängigkeiten installiert?
• Sagen die Rollen der Agenten, in welchen Ordnern sie arbeiten?
• Wurden vor dem Mergen Tests und ein Review durchgeführt?

Fazit

Git worktree parallel zu nutzen hält Agenten physisch getrennt, und Turns halten die eigenen Änderungen jedes Agenten umkehrbar. Zusammen sind sie die Grundlage, um sicher mit mehreren Agenten zu arbeiten.

AgentVera bringt Worktrees, Turns und das Git-Panel in ein Fenster. Lies es zusammen mit parallelen Coding-Agenten oder starte mit dem Free-Tarif.