Git-Worktrees: ein Gehirn, viele Agenten parallel am Werk

Stell dir ein einzelnes Repository mit mehreren klar getrennten Belangen vor - ein Frontend, ein Backend, etwas Infrastruktur, die CI/CD-Verdrahtung - und mehrere Agenten, die gleichzeitig daran arbeiten, jeder auf einem eigenen Branch. Sie sollen parallel vorankommen, ohne sich gegenseitig in die Quere zu kommen, und es soll eine zentrale Intelligenz geben, die ihre gesamte Arbeit auf einen Blick überschaut: das Diff eines Agenten prüfen, das eines anderen mergen, einen Konflikt auflösen, das Ganze kohärent halten. Die naheliegenden Antworten scheitern beide. Git-Worktrees sind die Antwort, die das nicht tut.

Das Problem: ein Checkout hält genau einen Branch

In einem normalen Klon kann immer nur ein Branch ausgecheckt sein. Schaltet Agent A das Arbeitsverzeichnis auf seinen Branch um, ändern sich Agent B die Dateien unter den Händen - alle sind an einen einzigen Schreibtisch serialisiert. Der naheliegende Ausweg sind N vollständige Klone, einer pro Agent. Das funktioniert, aber jeder Klon ist sein eigenes .git: eine vollständige Kopie der Historie, eigene Remotes, eigener Fetch-Zustand. Sie teilen keine Objekte und wissen lokal nichts voneinander, sodass das Verschieben eines Branch von einem zum anderen einen Umweg über das Remote bedeutet.

N Klone duplizieren die gesamte Historie und können Arbeit nur über das Remote austauschen. Worktrees behalten einen gemeinsamen Objektspeicher, sodass Branches nebeneinander liegen und sich je zwei davon lokal vergleichen oder mergen lassen.

Worktrees sind der Mittelweg: ein Repository - ein .git, ein Objektspeicher, ein Satz Branches - mit vielen Arbeitsverzeichnissen, jedes auf einen anderen Branch ausgecheckt, alle gleichzeitig aktiv. Isolation des Arbeitszustands, gemeinsame Nutzung der Historie.

Was ein Worktree tatsächlich ist

Stell dir ein Repository als Gehirn und Schreibtisch vor. Das Gehirn ist .git: die Objektdatenbank, die Refs, die Konfiguration. Der Schreibtisch ist das Arbeitsverzeichnis: die Dateien, die du tatsächlich bearbeitest. Ein normaler Klon schraubt genau einen Schreibtisch an ein Gehirn. Ein Worktree entkoppelt beide - ein Gehirn, viele Schreibtische.

Jeder Schreibtisch ist ein echtes Verzeichnis auf der Platte, auf einen Branch ausgecheckt, mit eigenem HEAD und eigenem Index (Staging-Bereich). Aber alle teilen denselben Objektspeicher, also gibt es keine duplizierte Historie, und ein zusätzlicher Schreibtisch kostet kaum Platz. Eine Regel schützt dabei alle: Derselbe Branch kann nicht in zwei Worktrees gleichzeitig ausgecheckt sein. Git verweigert das schlicht - und genau diese Verweigerung verhindert, dass zwei Agenten einen Branch beschädigen.

Ein .git-Objektspeicher hält die gesamte Historie und alle Branches; jedes Arbeitsverzeichnis checkt einen anderen Branch mit eigenem HEAD und Index aus. Schreibtische lassen sich günstig hinzufügen oder entfernen - das Gehirn bleibt gemeinsam.

Wie es funktioniert

Die gesamte Schnittstelle ist ein einziges Unterkommando. Aus deinem Haupt-Repo heraus fügst du einen Schreibtisch hinzu, richtest ihn auf einen Branch (neu oder bestehend), und git legt das Verzeichnis an und checkt ihn aus:

# du bist im Haupt-Repo (dem "main worktree")
cd ~/work/app

# ein Schreibtisch für den Backend-Agenten, auf einem brandneuen Branch
git worktree add ../wt-backend -b feature/be-auth

# der Frontend-Agent, sein eigener neuer Branch
git worktree add ../wt-frontend -b feature/fe-redesign

# der Infra-Agent, von einem bestehenden Branch aus
git worktree add ../wt-infra existing-infra-branch

git worktree list     # jeder Schreibtisch + der jeweilige Branch
git worktree remove ../wt-backend   # aufräumen, wenn fertig
git worktree prune    # veraltete Verwaltungseinträge entfernen

Auf der Platte hast du jetzt Geschwisterverzeichnisse - das Haupt-Repo plus wt-backend, wt-frontend, wt-infra - jedes auf einem anderen Branch. Unter der Haube tragen die sekundären Schreibtische kein vollständiges .git-Verzeichnis; sie halten nur eine winzige .git-Datei, die zurück in das .git/worktrees/<name>/ des Haupt-Repos zeigt. Es gibt nach wie vor nur einen Objektspeicher. Ein in einem Schreibtisch angelegter Branch ist sofort aus jedem anderen sichtbar, weil es nur ein Repository gibt.

Warum das das richtige Fundament für viele Agenten ist

Der gemeinsame Objektspeicher ist der ganze Sinn der Sache. Weil jeder Branch in einer einzigen Datenbank liegt, kann ein koordinierender Agent im main worktree quer über die Arbeit aller operieren, ohne ein Remote anzufassen: git log --all sieht alles, er kann je zwei Branches von Agenten diffen, dazwischen cherry-picken, mergen, Konflikte auflösen - alles lokal und sofort.

Parallele, isolierte Änderungen - jeder Agent besitzt ein Verzeichnis, also gibt es keine Dateikollisionen.
Ein Branch pro Agent - von git erzwungen; derselbe Branch kann nicht in zwei Schreibtischen aktiv sein.
Günstig hochzufahren und abzubauen - Schreibtische teilen sich die Objekte, also dauert das Anlegen oder Entfernen nur Sekunden.
Ein zentrales Gehirn - ein .git bedeutet eine Quelle der Wahrheit, über die der Orchestrator nachdenken kann: jeder Branch, jeder Commit, die gesamte Historie.
Unabhängige Builds und Tests - jeder Schreibtisch hat eigene node_modules, eigene Build-Ausgabe und eigene Caches, sodass die Agenten ihre Pipelines gleichzeitig laufen lassen, ohne sich gegenseitig zu überschreiben.

Der letzte Punkt wird leicht unterschätzt. Getrennte Arbeitsverzeichnisse bedeuten getrennten Build-Zustand: Ein Frontend-Agent kann seinen Dev-Server laufen lassen, während der Infra-Agent Terraform in einer Sandbox anwendet und der Backend-Agent seine Test-Suite ausführt - keiner streitet sich mit den anderen um dieselben Dateien.

Arbeitsweisen

Worktrees sind ein Fundament, keine Methode. Ein paar Muster passen sauber auf echte Teams und echte Agenten-Flotten.

Orchestrator und Worker

Der main worktree ist das zentrale Gehirn. Er startet einen Worker pro Worktree, jeden auf einem eigenen Branch. Die Worker committen auf ihre Branches; der Orchestrator integriert - merge, rebase, cherry-pick quer über sie hinweg, lokal - pusht dann und öffnet die Pull Requests. Das kommt "einer Intelligenz, viele Agenten" am nächsten.

Der Orchestrator lebt im main worktree und sieht jeden Branch auf einmal. Jeder Agent arbeitet in seinem eigenen Schreibtisch auf seinem eigenen Branch; der Orchestrator prüft, mergt lokal, pusht dann und öffnet PRs.

Ein Worktree pro Belang (langlebig) - wt-fe, wt-be, wt-infra, wt-cicd als halb-permanente Schreibtische, die deine Apps spiegeln. Am besten, wenn Agenten oder Teams sauber auf Subsysteme passen.
Ein Worktree pro Aufgabe (kurzlebig) - für jedes Feature oder jeden Bug einen frischen Schreibtisch hochfahren und ihn beim merge wegwerfen. Am besten, wenn die Arbeit eher aufgaben- als teamförmig ist.
Ein Integrations-Worktree - ein eigener Schreibtisch, in dem der Orchestrator alle laufend zusammenmergt, um Konflikte früh zu erwischen. Dein Kanarienvogel für die Frage "passt das alles noch zusammen?".

In Claude Code ist das eingebaut

Wenn du Agenten mit Claude Code steuerst, ist das Worktree-Muster nativ und nicht etwas, das du von Hand verdrahtest. Ein Sub-Agent lässt sich mit Worktree-Isolation starten - er läuft in seinem eigenen, automatisch angelegten Worktree, und der Schreibtisch wird danach aufgeräumt: das kurzlebige Muster, automatisiert. Es gibt außerdem Werkzeuge, um die aktuelle Sitzung in einen Worktree hinein und wieder heraus zu verschieben. So wird aus "eine zentrale Intelligenz, die N Agenten auf N Branches orchestriert": Diese Sitzung ist das Gehirn im main worktree, jeder gestartete Agent erhält seinen eigenen isolierten Worktree, und die Integration geschieht zurück im main-Schreibtisch.

Fallstricke, die man kennen sollte

Derselbe Branch in zwei Worktrees ist blockiert - und zwar bewusst. Gib jedem Schreibtisch einen eigenen Branch.
Build-Artefakte gibt es pro Worktree - node_modules und dergleichen werden nicht geteilt, also braucht jeder Schreibtisch sein eigenes Install. Meist genau das, was du für die Isolation willst, aber es kostet reale Platte und Zeit.
Verschachtle keinen Worktree im Repo - sonst versucht git, ihn als Dateien zu tracken. Halte Schreibtische als Geschwister (../wt-*), und ignoriere das Muster, falls du sie doch einmal innen behältst.
Nutze git worktree remove, nicht rm -rf - den Ordner von Hand zu löschen hinterlässt einen veralteten Verwaltungseintrag; git worktree prune räumt diese auf.
Hooks und Konfiguration sind gemeinsam - jeder Schreibtisch liest dasselbe .git/config und dieselben Hooks. Meist in Ordnung, gelegentlich überraschend.
Submodule sorgen über Worktrees hinweg für Reibung - wenn dein Repo sie nutzt, rechne mit zusätzlichem Setup pro Schreibtisch.

Das mentale Modell ist der ganze Trick: ein Gehirn, viele Schreibtische. Hör auf, ein Repository als Ordner zu sehen, in dem du Branches umschaltest, und fang an, es als eine einzige gemeinsame Historie zu sehen, aus der beliebig viele Arbeitsverzeichnisse gleichzeitig lesen können. Genau das lässt eine zentrale Intelligenz eine Flotte von Agenten koordinieren - jeder souverän auf seinem eigenen Branch - während die Historie, die sie alle teilen, die einzige Quelle der Wahrheit bleibt.