Ein paar Regeln haben sich inzwischen als sinnvoll erwiesen.
.claude/worktrees/ gehört in .gitignore
Sonst tauchen die vollständigen Arbeitskopien als unversionierte Dateien im Hauptcheckout auf. Spätestens bei einem unbedachten
git add -A
wird das unangenehm.
Also:
.claude/worktrees/
Ein Worktree pro Thema
Ich behandle einen Worktree ähnlich wie einen Branch: eine Aufgabe, ein Thema, möglichst ein Pull Request.
Wenn mehrere unabhängige Änderungen im selben Worktree landen, verliere ich einen großen Teil der Übersicht wieder.
Neue Themen möglichst vom Default-Branch starten
Ein Worktree für Task B sollte normalerweise nicht vom halbfertigen Branch von Task A abzweigen.
Sonst hängt der zweite Pull Request plötzlich vom ersten ab und beide lassen sich nicht mehr sauber unabhängig reviewen oder mergen.
git worktree list regelmäßig ansehen
Ich hatte tatsächlich drei Worktrees im Projekt liegen, einer davon gehörte zu einem Branch, der längst gemergt war.
Aufgefallen ist das nicht wegen eines Fehlers, sondern weil git status seit Tagen eine zusätzliche Zeile zeigte.
In solchen Setups ist
git worktree list
die verlässlichere Übersicht als offene Terminal-Tabs oder die Erinnerung daran, welche Agenten irgendwann einmal gestartet wurden.
Nach dem Merge sollte aufgeräumt werden:
git worktree remove <pfad>
git worktree prune
Parallelität braucht trotzdem ein WIP-Limit
Mit Worktrees kann man problemlos drei Agenten gleichzeitig Änderungen produzieren lassen. Danach gibt es aber auch drei Änderungen, die jemand verstehen und reviewen muss.
Damit wird häufig die verfügbare Review-Kapazität zur eigentlichen Grenze — nicht Git oder Claude Code.
Mehr parallele Agenten bedeuten nicht automatisch mehr Durchsatz. Irgendwann verschiebt sich der Engpass einfach vom Schreiben zum Review.
