WissenClaude Code & Vibe Coding
Claude Code Git Worktrees, parallel an mehreren Branches arbeiten
Ein Git Worktree ist ein zweites Arbeitsverzeichnis für dasselbe Repository, auf einem anderen Branch. Wie du damit mehrere Claude Code Sitzungen gleichzeitig laufen lässt.
Zwei Handwerker an derselben Baustelle, aber jeder mit eigenem Werkzeugkasten und eigenem Grundriss, damit sich keiner die Wände des anderen einreißt. Genau das macht ein Git Worktree für zwei Claude-Code-Sitzungen, die gleichzeitig an unterschiedlichen Branches arbeiten sollen.
Kurz gesagt
Ein Git Worktree ist ein zweites Arbeitsverzeichnis für dasselbe Repository, aber auf einem anderen Branch, ohne dass du das Repo ein zweites Mal klonen musst. Claude Code unterstützt das seit Version 2.1.49 direkt über den Schalter --worktree oder -w, der ein neues Verzeichnis samt Branch anlegt und die Sitzung sofort darin startet. So lassen sich mehrere Claude-Code-Sitzungen gleichzeitig fahren, jede auf ihrem eigenen Branch, ohne dass sich ihre Änderungen gegenseitig überschreiben.
Was ein Worktree technisch macht
Ein normales Git-Repository hat genau ein Arbeitsverzeichnis, wechselst du den Branch, ändern sich die Dateien darin. Ein Worktree hängt ein zweites Arbeitsverzeichnis an dieselbe Repository-Historie, mit einem eigenen Branch darin, aber ohne die Historie ein zweites Mal auf die Festplatte zu kopieren. Zwei Ordner, ein Repository. Für Claude Code bedeutet das: eine Sitzung im Hauptverzeichnis auf main, eine zweite Sitzung im Worktree auf feature-login, beide völlig unabhängig voneinander, keine Sitzung weiß von der anderen.
Native Unterstützung seit Anfang 2026
Bis Anfang 2026 mussten Worktrees noch von Hand über den normalen Git-Befehl angelegt werden, bevor Claude Code überhaupt gestartet wurde. Seit Version 2.1.49 übernimmt Claude Code das selbst: claude --worktree auth-fix legt Verzeichnis und Branch in einem Schritt an und startet die Sitzung direkt darin, ganz ohne manuellen Zwischenschritt.
Wann sich das für dich lohnt
Der Unterschied zu Subagents ist wichtig: ein Subagent delegiert eine Teilaufgabe innerhalb derselben Sitzung und desselben Branches, ein Worktree eröffnet eine komplett eigene, von dir selbst gesteuerte Sitzung auf einem anderen Branch. Sinnvoll wird das, wenn du wirklich zwei unabhängige Aufgaben parallel vorantreiben willst, etwa einen dringenden Bugfix, während an einem neuen Feature weitergebaut wird, ohne den halbfertigen Stand der Feature-Sitzung zu unterbrechen. Für eine einzelne Aufgabe nacheinander bringt ein Worktree dagegen nichts, außer zusätzlicher Verwaltung.
Aufräumen nicht vergessen
Schließt du die Claude-Code-Sitzung, bleibt der Worktree bewusst stehen, Verzeichnis und Branch verschwinden nicht von selbst. Erst wenn du den Branch gemergt oder verworfen hast, räumst du mit git worktree remove <pfad> und danach git worktree prune wieder auf. Sonst sammeln sich über die Zeit verwaiste Verzeichnisse an, die niemand mehr braucht.
Ich denke, Worktrees lohnen sich für einen Solounternehmer seltener, als das Feature vermuten lässt. Die meiste Zeit arbeitest du ohnehin an einer Sache nach der anderen. Interessant wird es erst, sobald du wirklich zwei Baustellen gleichzeitig offen hast, die beide Aufmerksamkeit brauchen, und nicht bloß eine wartende Pipeline im Hintergrund laufen lassen willst.
Quellen: Run Multiple Claude Code Sessions in Parallel With Git Worktrees (MindStudio) · Claude Code Worktrees: The Complete Guide (crystl.dev) · The Complete Guide to Git Worktrees with Claude Code (AI Agent Engineering Notes)
Häufige Fragen
Braucht jeder Worktree eine eigene Installation der Abhängigkeiten?
Ja, weil es ein eigenständiges Verzeichnis ist. Bei einem Node-Projekt zum Beispiel läuft in jedem Worktree ein eigenes npm install, das kostet etwas Plattenplatz und Zeit beim Anlegen.
Kann ich mehr als zwei Worktrees gleichzeitig offen haben?
Ja, technisch beliebig viele. Sinnvoll bleibt es aber nur so lange, wie du selbst noch den Überblick behältst, welche Sitzung an welchem Branch gerade was macht.
Ersetzt ein Worktree einen zweiten Klon des Repositories?
Für die meisten Zwecke ja, und schneller, weil die Historie nicht doppelt auf der Festplatte liegt, sondern geteilt wird.
Willst du das bei dir umsetzen?
In der Community zeige ich, was bei mir hält. Im Erstgespräch schauen wir uns dein Vorhaben konkret an.