Claude —worktree: Wenn die KI-Klone gleichzeitig in die Tasten hauen

Kürzlich stolperte ich über diesen Post von Boris Cherny auf X , und mein erster Reflex war: „Moment mal… das kann doch gar nicht funktionieren, oder?”

Die Rede ist vom neuen Flag claude --worktree in Claude Code. Die Versprechung: Man kann mehrere Claude-Instanzen gleichzeitig auf dasselbe Repo loslassen, um an unterschiedlichen Features zu arbeiten.

Mein Hirn schaltete sofort in den Git-Panik-Modus: „Zwei Terminals im selben Verzeichnis? Am Ende mache ich in beiden einen Commit? Das gibt doch die Mutter aller Merge-Konflikte!”

Ich habe mich mal für euch (und für mich) durch das Kaninchenloch gegraben. Hier ist die Auflösung, warum das kein Chaos verursacht, sondern mein neues Lieblings-Tool für den Berufsalltag wird.

Das Problem mit der „Warte-Minute”

Wir kennen das: Man bittet Claude, ein komplexes Refactoring durchzuführen oder eine Test-Suite zu schreiben. Das dauert vielleicht 60 Sekunden. In der Zeit könnte man eigentlich schon am nächsten CSS-Bug schrauben.

Aber man traut sich nicht, im Verzeichnis rumzufuschen, während die KI gerade die Dateien liest und schreibt. Man ist blockiert.

Die Lösung: Git Worktrees (Die Magie im Hintergrund)

Hier kommt der Trick: Claude nutzt ein mir bislang nur dem Namen nach bekanntes Git-Feature namens Worktrees.

Stellt euch vor, ihr habt ein Buch (euer Repo). Normalerweise könnt ihr es nur an einer Stelle gleichzeitig aufschlagen. Ein Git Worktree ist so, als würde man eine magische Kopie des Buches in einen anderen Raum legen. Beide Kopien teilen sich denselben “Speicher” (die Git-Datenbank), aber ihr könnt in Raum A auf Seite 10 schreiben und in Raum B auf Seite 200 – ohne euch gegenseitig die Stifte aus der Hand zu nehmen.

Wenn ihr claude --worktree startet, passiert folgendes:

1. Claude erstellt im Hintergrund blitzschnell einen neuen Branch.
2. Er checkt diesen Branch in ein separates Verzeichnis aus (versteckt unter .claude/worktrees/).
3. Ihr arbeitet also gar nicht in derselben Instanz.

Mein neuer Workflow: Spezialisten und ein Integrator

Nachdem ich das kapiert hatte, ergab die Arbeitsweise plötzlich Sinn. Ich teile die Rollen jetzt auf:

1. Die Spezialisten (Die „Arbeitstiere”)

In Terminal 1 sage ich:

claude --worktree

→ „Bau mir die API-Anbindung für das Wetter-Widget.”

In Terminal 2 sage ich:

claude --worktree

→ „Fix das responsive Layout im Header.”

Beide Claudes schuften in ihrer eigenen Blase. Sie sehen sich nicht, sie stören sich nicht. Wenn sie fertig sind, committen sie ihre Arbeit in ihren eigenen kleinen Feature-Branch.

2. Der Integrator (Der „Chef-Entwickler”)

Das bin ich (mit Hilfe des normalen claude-Befehls) in meinem Hauptverzeichnis. Hier laufen die Fäden zusammen. Ich mache einen git merge der beiden KI-Branches.

Und ja, falls beide an derselben Datei geschraubt haben, knallt es hier. Aber das ist ein guter Knall.

Der „Aha”-Moment bei Merge-Konflikten

Das war meine größte Sorge: Wer löst das Chaos auf?

Die Antwort ist simpel: Ich frage den Claude im Hauptverzeichnis. Da er den Überblick über das gesamte Projekt hat, sage ich einfach:

„Hey Claude, ich habe hier einen Merge-Konflikt zwischen dem Wetter-Widget und dem Header-Fix. Bitte schau dir die Änderungen an und kombiniere sie so, dass beides funktioniert.”

Da die KI den Code-Kontext beider Änderungen versteht, löst sie den Konflikt oft intelligenter als ich es händisch mit <<<<<<< HEAD Markern könnte.

Fazit: Willkommen in der parallelen Welt

claude --worktree ist für mich ein Gamechanger. Es nimmt das „Serielle” aus dem Programmieren. Ich muss nicht mehr warten, bis die KI fertig ist, um weiterzudenken.

Pro-Tipp für die Git-Sauberkeit: Vergesst nicht, ab und zu mit git worktree prune aufzuräumen, damit eure Festplatte nicht irgendwann voller „spicy-napping-otter” oder „clever-munching-toast” Verzeichnisse ist (ja, so benennt Claude diese Worktrees tatsächlich).

Wie sieht’s bei euch aus? Nutzt ihr Worktrees schon aktiv? Schreibt’s mir als Feedback - ich hab diese Feature soeben eingeführt!

Nachtrag: —worktree in der Praxis

Nach einigen Tests muss ich den ursprünglichen Beitrag relativieren: Für meine konkrete Arbeit mit Next.js/React ist --worktree nicht geeignet.

Das Problem

--worktree isoliert nicht nur räumlich, sondern auch konzeptionell. Was das bedeutet:

• .env-Dateien sind zwar im tree-Listing sichtbar, aber nicht verfügbar
• Nur versionierte Dateien (git) sind wirklich zugänglich
• Build-Tools wie bun run dev oder Next.js Devtools funktionieren nicht
• node_modules, Build-Cache, lokale Konfiguration – alles fehlt

Man merkt es nicht sofort, weil die Verzeichnisstruktur normal aussieht. Aber sobald man etwas ausführen will, stößt man gegen Wände.

Wofür —worktree tatsächlich gut ist

• Isolierte Code-Reviews
• Kleine, abgeschlossene Refactorings
• Debugging einzelner Komponenten ohne Umgebungsabhängigkeiten

Nicht für:

• Laufende Entwicklungsumgebungen
• Projekte mit Build-Prozessen
• Alles, was .env, node_modules oder andere lokale Ressourcen braucht

Meine Empfehlung

Für Next.js/React-Projekte: Verzichte auf --worktree.

Arbeite direkt im Projektverzeichnis:

cd /pfad/zu/deinem/projekt
claude

Claude hat genug Kontext durch die Dateistruktur – und du hast Zugriff auf die komplette Umgebung.

TL;DR: --worktree klingt clever, ist aber für produktive Entwicklung oft unpraktisch. Manchmal ist der einfache Weg der bessere.

Dieser Beitrag erschien zuerst auf martuni.de