Parallele Coding-Agents in Git-Worktrees betreiben

Lass zwei Coding-Agents im selben Checkout laufen, und du verstehst schnell, warum Softwareteams Branches benutzen. Ein Agent benennt ein Modul um, während der andere die Testsuite gegen die halbe Umbenennung laufen lässt. Einer staged Dateien, die der andere gerade gelöscht hat. Keiner macht etwas falsch – sie teilen sich nur einen Schreibtisch.

SuperDevSpace lässt einen Manager und mehrere Worker gleichzeitig auf einem Repository arbeiten. Dieser Artikel erklärt den Mechanismus, der sie auseinanderhält – Git-Worktrees – und die genauen Regeln, die die App dabei befolgt.

Was ein Git-Worktree ist

Ein Git-Repository hat normalerweise ein Arbeitsverzeichnis. Mit git worktree bekommt ein Repository mehrere, jedes auf einem eigenen Branch ausgecheckt, alle mit derselben Objektdatenbank. Es gibt keinen zweiten Clone und keine zweite Kopie der History: Ein neuer Worktree kostet die Dateien eines Checkouts und sonst nichts.

Du kannst es in jedem Repository von Hand ausprobieren. Die Befehle sind überall gleich, nur die Shell unterscheidet sich:

git worktree add -b agent/frontend-demo ../myrepo-frontend
git worktree list
cd ../myrepo-frontend && git status
cd - && git worktree remove ../myrepo-frontend

git worktree add -b agent/frontend-demo ..\myrepo-frontend
git worktree list
cd ..\myrepo-frontend; git status
cd ..\myrepo; git worktree remove ..\myrepo-frontend

Jeder Worktree hat seinen eigenen HEAD, seinen eigenen Index und seine eigenen Dateien. Zwei Prozesse können in zwei Worktrees gleichzeitig editieren, bauen und testen, ohne die halbfertigen Änderungen des anderen zu sehen. Genau diese Eigenschaft braucht ein Team aus Agents.

Wie SuperDevSpace sie nutzt

Die Regeln sind einfach und für jede Organisation gleich:

• Der Manager arbeitet in deinem Haupt-Checkout. Er plant, prüft und merged; dort kommen die Branches zusammen.
• Jeder Worker bekommt seinen eigenen Worktree auf einem eigenen Branch. Stellt der Manager einen Worker ein, führt die App für ihn git worktree add -b <branch> <pfad> aus. Der Branch heißt agent/<worker-name>-<stempel>, sofern du ihm keinen eigenen Namen gegeben hast.
• Worktrees liegen im Datenordner der App, unter worktrees/<organisation>/<worker>, nie in deinem Repository. Dein Projektordner füllt sich nicht mit Agent-Verzeichnissen.
• Jeder Durchgang wird committet. Beendet ein Worker einen Durchgang, committet die App alles, was sich in seinem Worktree geändert hat (agent(<name>): turn). Nichts, was ein Worker getan hat, existiert nur in einem nicht committeten Arbeitsverzeichnis.
• Gemerged wird per Squash-Merge. Akzeptiert der Manager den Bericht eines Workers, wird der Branch mit git merge --squash als ein Commit in deine Linie gemerged. Gibt es einen Konflikt, bricht die App den Merge ab und hinterlässt das Repository sauber für die nächste Operation, statt dich mitten in einem Konflikt stehen zu lassen.
• Eine Git-Operation pro Repository auf einmal. Die Worktree-Verzeichnisse trennen die Dateien; eine Warteschlange pro Repository serialisiert die Git-Befehle selbst. Zwei Worker, die im selben Moment fertig werden, konkurrieren nie um Gits Metadaten.

Diagramm als Text

gitGraph
  commit id: "main"
  branch agent/frontend
  commit id: "frontend: Durchgang 1"
  checkout main
  branch agent/qa
  commit id: "qa: Durchgang 1"
  checkout agent/frontend
  commit id: "frontend: Durchgang 2"
  checkout main
  merge agent/frontend id: "squash: frontend"
  merge agent/qa id: "squash: qa"

Auf dem Board sieht das aus wie mehrere Aufgaben gleichzeitig in Arbeit, jede bei einem anderen Worker, jede mit ihrem eigenen Branch darunter.

Was es praktisch macht

Ein frischer Worktree enthält nur, was Git verfolgt. Das reicht meist nicht, um ein Projekt zu starten: node_modules, eine lokale .env, generierte Dateien. Zwei Details lösen das.

Ein Setup-Skript pro Repository

Hat dein Repository eine .super/scripts/setup-worktree.sh, führt die App sie in jedem neuen Worktree aus, bevor der Worker startet, mit SUPERDEV_MAIN_REPO als Verweis auf deinen Haupt-Checkout. Die Ausgabe wird live gestreamt – eine lange Installation ist also kein Blindflug –, und du kannst sie abbrechen.

#!/usr/bin/env bash
set -euo pipefail
# Nur lokal vorhandene Dateien aus dem Haupt-Checkout kopieren
cp "$SUPERDEV_MAIN_REPO/.env" .env 2>/dev/null || true
# Abhängigkeiten installieren (pnpm verlinkt aus einem gemeinsamen Store, das geht schnell)
pnpm install --frozen-lockfile

Submodules

git worktree add lässt Submodules leer. Hat der neue Worktree eine .gitmodules-Datei, führt die App darin git submodule update --init --recursive aus, damit kein Worker gegen eine stillschweigend fehlende Abhängigkeit baut.

Aufräumen, ohne Arbeit zu verlieren

Worktrees sammeln sich an. Die App räumt sie auf, aber vorsichtig:

Diagramm als Text

flowchart TD
  start["Worker ist fertig"] --> clean{"Arbeitsbaum sauber?"}
  clean -->|"nein"| keep["Worktree bleibt"]
  clean -->|"ja"| merged{"Branch in deine Linie gemerged?"}
  merged -->|"nein"| keep
  merged -->|"ja"| remove["Worktree wird entfernt"]

Ein Worktree mit nicht committeten Änderungen oder mit einem Branch, dessen Arbeit noch nicht in deiner Linie ist, bleibt, wo er ist. Ein gelöschter Ordner lässt sich neu anlegen; verlorene Arbeit nicht. Dieselbe Vorsicht gilt für Branches: Die App merkt sich die Branches, die sie angelegt hat, und fasst nur diese an.

Was sich für dich ändert

Mit jedem Worker auf einem eigenen Branch ist „vier Agents gleichzeitig laufen lassen“ kein Glücksspiel mehr. Du kannst:

• dem Manager eine Direktive geben, die in unabhängige Aufgaben zerfällt, und die Worker parallel laufen lassen;
• den Diff jedes Workers einzeln lesen, neben dem Gespräch, das ihn erzeugt hat;
• die Änderung eines Workers ablehnen, ohne die anderen zu stören;
• deinen Haupt-Checkout selbst weiter benutzen, während das Team arbeitet.

Es ist dieselbe Disziplin, die ein menschliches Team nutzt – angewandt auf Agents, die dir nicht sagen können, dass sie sich gleich gegenseitig auf die Füße treten. Wenn du dich fragst, warum wir darum eine ganze App gebaut haben, erzählt der erste Artikel die Geschichte.

Ausprobieren

Die 14-tägige Testphase ist Premium, ohne Karte. Lade SuperDevSpace herunter, richte eine neue Organisation auf ein Repository und sieh zu, wie die Worktrees entstehen, während der Manager seine ersten Worker einstellt.