Claude Code-Sitzungen nacheinander auszuführen ist eine Gewohnheit, keine Notwendigkeit. Wenn deine Aufgaben wirklich unabhängig sind, gibt es keinen Grund, dass die eine auf die andere warten muss. Git-Worktrees geben jeder Claude-Sitzung ihr eigenes ausgechecktes Verzeichnis auf ihrem eigenen Branch, alle bedienen sich aus demselben .git-Objektspeicher. Keine duplizierten Klone, keine Dateikonflikte, Standard-git merge wenn du fertig bist. Dieser Beitrag geht durch den kompletten Workflow: wann ein Worktree hilfreich ist, wie man es aufbaut, welche Isolation man tatsächlich bekommt (und welche nicht), und wie man aufräumt, ohne Arbeit zu verlieren, die noch nicht committed wurde.
Wann ein Worktree Sinn macht
Nicht jede Aufgabe rechtfertigt eines. Ehrliche Antwort: Worktrees glänzen in einem ziemlich spezifischen Spektrum von Situationen.
Eine YouTube-Anleitung von bri (Juni 2026) fasst es gut zusammen. Nutze ein Worktree, wenn du zwei oder mehr Aufgaben hast, die nicht dieselben Dateien betreffen, oder wenn eine Aufgabe riskant genug ist, dass du zwei verschiedene Ansätze sehen möchtest, bevor du dich auf einen festlegst. Wenn eine einzelne Aufgabe das ganze Codebase umfasst, bleib bei einer Sitzung. Gleiches gilt für explorative Arbeit, bei der der Agent frei umherstreifen soll.
Der andere gute Use-Case: spekulative Arbeit. Starte drei Worktrees, gib jedem einen leicht unterschiedlichen Prompt für dasselbe Problem, und wähle die Version die dir gefällt. Zylos Research merkt an, dass dieses Muster bei Teams mit vier oder mehr gleichzeitigen KI-Sitzungen üblich geworden ist, genau weil du dich gegen nicht-deterministische Modellausgaben absicherst, anstatt dich auf einen einzelnen Durchgang zu verlassen.
Umgekehrt: Wenn dein Projekt ein großes TypeScript-Monorepo mit PostgreSQL, Redis, mehreren internen Packages und einem Remix-Frontend umfasst, werden Worktrees allein deine Koordinationsprobleme nicht lösen. Trigger.dev schrieb genau darüber und wechselte schließlich zu einem anderen Ansatz. Die Dateisystem-Isolation ist real. Die Service-Isolation ist nicht automatisch.
Isolierte Task-Checkouts erstellen
Starte auf deinem Base-Branch und ziehe die Neueste Version. Füge dann .claude/worktrees einmalig zu deiner .gitignore hinzu:
echo ".claude/worktrees" >> .gitignore
Claude platziert Worktrees standardmäßig in deinem Repo-Verzeichnis. Ohne diesen .gitignore-Eintrag werden sie als unverfolgtes Dateien angezeigt und überladen dein git status. Füg es hinzu, commit es, und vergiss es.
Starte nun eine Sitzung pro Aufgabe. Öffne zwei Terminals:
claude --worktree feature-payments
``
claude --worktree bugfix-auth
Nach Dan Does Code's Artikel erstellt Claude das Worktree unter .claude/worktrees/feature-payments/, checkt einen neuen Branch aus und begrenzt die Sitzung auf dieses Verzeichnis. Dein Haupt-Worktree bleibt die ganze Zeit unverändert. Du kannst auch das Short-Flag claude -w feature-payments verwenden, wenn du das bevorzugst. Lasse den Namen weg und Claude generiert automatisch einen.
Jede Sitzung läuft nun in vollständiger Dateisystem-Isolation. Der Agent in Terminal 1 kann die Dateien, an denen der Agent in Terminal 2 arbeitet, nicht anfassen, weil sie sich in verschiedenen Verzeichnissen auf verschiedenen Branches befinden. Das ist der ganze Trick. Es ist Isolation auf Infrastrukturebene, nicht Koordinationslogik zwischen Agenten. (Das Claude Code-Subagenten-Guide behandelt die Orchestrierungsseite, falls das das ist, das du stattdessen suchst.)
Jeder Sitzung ihre Aufgabe geben
Sobald beide Sessions laufen, geben Sie jeder ihre Anweisungen. Behandeln Sie jede Claude-Instanz als frischen Context. Seien Sie konkret bezüglich des Umfangs. Wenn Terminal 1 ein Zahlungsfeature entwickelt, teilen Sie mit, welche Dateien zu ändern sind und welche zu ignorieren. Dasselbe für Terminal 2.
Wenn eine Session abgeschlossen ist, bitten Sie Claude, den Branch zu pushen und einen Pull Request zu öffnen, bevor Sie das Terminal schließen. So ist die Arbeit sicher von Ihrem lokalen Rechner weg und bereit zur Überprüfung.
Abhängigkeiten, Ports und lokale Konfiguration verwalten
Hier wird es knifflig. Dateisystem-Isolation funktioniert automatisch. Alles andere erfordert etwas manuelle Vorbereitung.
Ports. Wenn beide Worktrees einen Dev-Server starten, kollidieren sie standardmäßig auf denselben Port. Die Lösung besteht darin, jede Worktree mit einer eigenen .env-Datei mit unterschiedlicher Port-Zuweisung auszustatten. Etwa PORT=3001 in einer und PORT=3002 in der anderen. Oder übergeben Sie den Override inline beim Start. Beide Varianten funktionieren.
Datenbanken. SQLite ist einfach: Zeigen Sie jede Worktree's .env auf einen anderen Dateipfad. PostgreSQL oder MySQL erfordert mehr Überlegung. Sie benötigen entweder eine separate Datenbankinstanz pro Worktree oder mindestens ein separates Schema/eine separate Datenbank in derselben Instanz. Konfigurieren Sie die Verbindungszeichenfolge über Umgebungsvariablen in der .env jeder Worktree. Teilen Sie keine Datenbank zwischen zwei Agenten, die gleichzeitig Migrationen schreiben. Das führt zu Beschädigungen oder Race Conditions.
Lokale Config-Dateien. Wenn Ihr Projekt eine nicht committete lokale Config-Datei verwendet (etwa .env.local, config/local.yml), müssen Sie eine pro Worktree erstellen. Sie erben nicht automatisch vom Haupt-Worktree.
MindStudio's Leitfaden zu parallelen KI-Coding-Agenten behandelt diese Isolationsmuster ausführlicher. Die Kurzfassung: Worktrees bieten Branch- und Verzeichnis-Isolation standardmäßig. Datenbank- und Port-Isolation erfordert explizite, vorausgehende Konfiguration.
Noch etwas, das erwähnenswert ist. Wenn Sie an einem Projekt mit aufwändiger oder komplizierter lokaler Service-Einrichtung arbeiten und mehrere Worktrees laufen, überlegen Sie, ob sich die Setup-Kosten durch den Parallel-Speedup lohnen. Bei einer Library oder einem CLI-Tool: definitiv. Bei einem Full-Stack-Monorepo mit sechs Services: vielleicht weniger. Falls Sie Hilfe bei der Scoping benötigen, kann ein Claude Code Developer bewerten, ob Worktrees oder eine andere Parallel-Strategie zu Ihrem Stack passt.
Überprüfung und Integration beider Branches
Beide Agenten sind fertig. Beide Branches sind gepusht. Jetzt folgt die Überprüfung.
Der Workflow ist Standard-Git. Die Parallel-Einrichtung ändert nichts am Merge-Prozess. Eine nummerierte Abfolge für ein typisches Zwei-Task-Repo:
Mainauschecken und auf den neuesten Stand bringen.- Überprüfen Sie den ersten Branch.
git diff main..feature-paymentszeigt Ihnen vollständig, was sich geändert hat. - Falls zufrieden, mergen oder rebasen Sie in
main. Lösen Sie Konflikte mit dem Basis-Branch wie gewohnt. - Pullen Sie
mainerneut, um diese Änderungen zu erhalten. - Überprüfen Sie den zweiten Branch.
git diff main..bugfix-auth. - Mergen. Falls die zwei Agenten überlappende Dateien berührt haben (sollte nicht vorkommen, wenn Sie Tasks korrekt eingegrenzt haben, kommt aber manchmal vor), lösen Sie Konflikte hier.
- Führen Sie Ihre Test-Suite gegen
mainaus, sobald beide Merges eingepflegt sind.
Der Vorteil der sequenziellen Überprüfung wie hier, statt beide gleichzeitig zu mergen, liegt darin, dass Konflikte aus einem Merge nicht in den nächsten hineinwirken. Einfachere Diffs, leichter nachzuvollziehen.
Aufräumen ohne Verlust von nicht committeter Arbeit
Cleanup ist, wo Entwickler nervös werden. Was ist, wenn es Arbeit in einer Worktree gibt, die nie committetet wurde?
Die Lösung: Stashen Sie es, bevor Sie den Worktree entfernen.
Wenn Sie ungespeicherte Änderungen in einem Worktree haben, den Sie behalten möchten, navigieren Sie in dieses Worktree-Verzeichnis und führen Sie aus:
git stash push -m "wip: payments feature - pre-cleanup"
Dieser Stash befindet sich im gemeinsamen .git-Objektspeicher, das heißt, er ist nach dem Entfernen des ursprünglichen Worktrees von Ihrem Haupt-Worktree oder einem beliebigen anderen Worktree aus zugänglich. Sobald Sie gestasht haben, können Sie sicher löschen:
git worktree remove .claude/worktrees/feature-payments
Dann, zurück in Ihrem Haupt-Worktree, poppen Sie den Stash:
git stash pop
Wenn das Experiment völlig fehlgeschlagen ist und Sie nichts davon verwenden möchten, löschen Sie einfach ohne zu stashen. git worktree remove mit dem --force Flag entfernt den Worktree auch wenn er ungespeicherte Änderungen hat. Seien Sie sich sicher, bevor Sie --force nutzen. Es gibt keinen Wiederherstellungsweg.
Nach dem Entfernen aller Worktrees die Liste aufräumen:
git worktree prune
Das entfernt veraltete administrative Referenzen aus .git/worktrees/.
Gemeinsame Ressourcen, die Worktrees nicht isolieren
Es ist wichtig, das explizit zu sagen, weil das Denkmodell von „Isolierung" Sie irreführen kann.
Was Worktrees isolieren:
- Das Arbeitsverzeichnis und alle Dateien darin
- Der Branch, auf dem jede Sitzung arbeitet
- Eingefügte und nicht eingefügte Änderungen
Was Worktrees nicht isolieren:
- Der
.git-Objektspeicher (konstruktionsbedingt gemeinsam) - Maschinenlokal automatischer Speicher (die offizielle Dokumentation bestätigt, dass Worktrees desselben Repositorys diesen gemeinsam nutzen)
- Externe Services: Datenbanken, Warteschlangen, Caches, jegliche Netzwerkabhängigkeit
- Umgebungsanmeldedaten und API-Schlüssel, es sei denn, Sie setzen explizit unterschiedliche Werte pro Worktree
- Alles in Ihrer Betriebssystem-Shell-Umgebung, die beide Sitzungen erben
Das ist auch aus Sicherheitsgründen wichtig. Worktrees sind keine Mandantengrenzen. Wenn beide Sitzungen denselben API-Schlüssel oder dieselben Datenbankzugangsdaten gemeinsam nutzen, teilen sie den Zugriff. Behandeln Sie einen Worktree nicht als Möglichkeit, eine Claude-Sitzung von empfindlicher lokaler Konfiguration zu isolieren. Das ist er nicht.
Für die Orchestrierung mehrerer Agenten in einem breiteren Workflow, nicht nur für Dateisystem-Isolierung, gibt der Claude Code superpowers-Beitrag weitere Muster vor.
FAQ
Funktioniert `claude --worktree` gleich wie das manuelle Ausführen von `git worktree add`?
Funktional ähnlich, aber nicht identisch. claude --worktree führt git worktree add aus, erstellt den Branch und begrenzt die Claude-Sitzung auf dieses Verzeichnis in einem Schritt. Wenn Sie git worktree add manuell ausführen und dann Claude im resultierenden Verzeichnis starten, erhalten Sie das gleiche Dateisystem-Ergebnis, aber ohne Claudes eingebaute Scoping. Das --worktree Flag ist der schnellere Weg für den häufigen Fall.
Kann ich mehr als zwei Worktrees gleichzeitig ausführen?
Ja. Es gibt keine harte Grenze, die von git oder Claude Code für die Anzahl der Worktrees vorgegeben wird. Die praktische Grenze ist der RAM und die CPU deines Rechners. Jede Claude-Sitzung ist ein separater Prozess mit eigenem Kontext. Drei oder vier gleichzeitige Sitzungen auf einem modernen Dev-Rechner sind kein Problem. Darüber hinaus wirst du wahrscheinlich auf Ressourcengrenzen treffen, bevor du an eine git-Limitation stößt.
Was passiert mit dem Branch eines Worktrees, wenn ich das Worktree lösche?
Der Branch bleibt erhalten. git worktree remove löscht das Arbeitsverzeichnis und die administrative Referenz in .git/worktrees/. Der Branch selbst bleibt und ist aus deinem Haupt-Arbeitsbaum oder jedem anderen Worktree zugänglich. Du löschst den Branch separat mit git branch -d branch-name, wenn du ihn nicht mehr brauchst.
Beeinflussen Worktrees, wie Claude die Projektgedächtnis-Datei CLAUDE.md liest oder schreibt?
Worktrees im gleichen Repository teilen sich das maschinenlokal gespeicherte automatische Gedächtnis gemäß der offiziellen Dokumentation. Falls du eine CLAUDE.md-Datei im Repo committed hast, liest jedes Worktree sie aus seiner eigenen checked-out-Kopie. Änderungen, die ein Agent an CLAUDE.md in seinem Worktree vornimmt, bleiben auf diesem Branch isoliert, bis sie gemergt werden. Aber die maschinenlokal gespeicherte Ebene wird geteilt, daher sind Anweisungen, die dort von einer Sitzung geschrieben wurden, für eine andere Sitzung sichtbar.
Gibt es einen Leistungsaufwand beim Betreiben von Worktrees gegenüber separaten Klonen?
Worktrees sind günstiger als Klone. Sie teilen sich den .git-Objektspeicher, daher gibt es keine Vervielfachung der gesamten Repository-Verlaufs auf der Festplatte. Die Hauptkosten entstehen durch das Arbeitsverzeichnis selbst, das ein vollständiges Checkout aller verfolgten Dateien im aktuellen Zustand des Branches ist. Bei großen Repositories mit Binärdateien oder generierten Dateien kann sich diese Checkout-Größe summieren. Aber git-Operationen (fetch, log, diff) laufen alle gegen einen einzelnen Objektspeicher, daher sind sie schnell.
Der sauberste Grund, Worktrees gegenüber separaten Klonen zu bevorzugen: Stashes und Refs, die in einem Worktree erstellt werden, sind sofort überall sonst im gleichen Repo zugänglich. Genau dieser gemeinsame Zustand macht den oben beschriebenen Cleanup-Workflow möglich.