Git Worktrees & parallele Arbeitsstränge
- Was ein Git-Worktree ist — ein Repo, mehrere Arbeitsverzeichnisse, jedes auf seinem eigenen Branch
- Das genaue Problem, das er löst: parallele Claude-Sitzungen daran hindern, an denselben Dateien zu kollidieren
- Die vier Befehle zum Hinzufügen, Auflisten und Entfernen von Worktrees
- Wann sich die Technik lohnt — und die drei Fallstricke, die beim Mergen zubeißen
- Wie Worktrees mit Subagenten zusammenspielen: Parallelität über Sitzungen hinweg vs. innerhalb einer
Ein Git-Worktree ermöglicht es einem Repository, mehrere Arbeitsverzeichnisse zu haben, jedes auf einen anderen Branch ausgecheckt. Kombiniert mit Claude Code kannst du mehrere Sitzungen parallel auf demselben Projekt ausführen — jede bearbeitet ihre eigenen Dateien, ohne Kollisionen.
Das Problem, das er löst
Wenn zwei Claude-Sitzungen gleichzeitig dasselbe Arbeitsverzeichnis bearbeiten, stolpern sie über die Änderungen der jeweils anderen. Worktrees geben jeder Sitzung ihr eigenes Verzeichnis und ihren eigenen Branch, sodass parallele Arbeit isoliert bleibt, bis du mergst.
Die Grundlagen
Vier Befehle tragen den ganzen Workflow: einen Worktree hinzufügen (neues Verzeichnis + neuer Branch), auflisten, was existiert, und einen entfernen, wenn du fertig bist.
- Von deinem Repo aus erstellt git worktree add ../app-feature-a -b feat-a ein neues Verzeichnis UND einen neuen Branch in einem Schritt.
- git worktree add ../app-fix-123 -b fix-123 — ein zweites isoliertes Verzeichnis/Branch, neben dem ersten.
- git worktree list zeigt jedes Arbeitsverzeichnis und den Branch, auf dem es liegt.
- git worktree remove ../app-feature-a baut einen Worktree ab, damit sich keine veralteten Verzeichnisse ansammeln.
The four-command workflow
# from your repo git worktree add ../app-feature-a -b feat-a # new dir + new branch git worktree add ../app-fix-123 -b fix-123 git worktree list # when done with one: git worktree remove ../app-feature-a
Öffne in jedem Worktree-Verzeichnis eine Claude-Code-Sitzung und lass sie unabhängig arbeiten.
Wann es sich lohnt
- Parallele Features/Fixes, die du gleichzeitig voranbringen willst.
- Eine lange laufende Aufgabe in einem Worktree, während du in einem anderen weiterarbeitest.
- Riskante Experimente, isoliert von deinem Haupt-Checkout.
Fallstricke
- Achte auf den Merge-Back: Branches werden irgendwann gemergt — Konflikte tauchen dann auf, nicht währenddessen. Halte Worktrees fokussiert und kurzlebig.
- Führe keine zustandsbehafteten, gemeinsamen Ressourcen (eine Dev-DB, einen Port) aus zwei Worktrees aus, ohne sie zu trennen.
- Räume mit git worktree remove auf, damit sich keine veralteten Verzeichnisse ansammeln.
Worktrees vs. Subagenten
Zwei verschiedene Achsen der Parallelität — sie konkurrieren nicht, sie stapeln sich.
| Was es parallelisiert | Isolation | |
|---|---|---|
| Subagenten | Arbeit innerhalb einer Sitzung (Delegation) | Isolierter Kontext |
| Worktrees | Arbeit über Sitzungen hinweg auf der Festplatte | Isolierte Branches/Dateien |
Sie spielen gut zusammen: Eine Sitzung in einem Worktree kann selbst Subagenten starten.
- Nutze einen Worktree, wenn du zwei Claude-Sitzungen brauchst, die gleichzeitig dasselbe Repo berühren; nutze einen Subagenten, wenn eine Sitzung einen Teil der Arbeit in isolierten Kontext auslagern muss.
Teste dich selbst
0/4- Ein Git-Worktree = ein Repo, mehrere Arbeitsverzeichnisse, jedes auf seinem eigenen Branch — die Basis für kollisionsfreie parallele Claude-Sitzungen.
- Zwei Sitzungen auf einem Arbeitsverzeichnis stolpern übereinander; ein Worktree pro Sitzung hält Dateien und Branches isoliert, bis du mergst.
- git worktree add ../dir -b branch erstellt Verzeichnis + Branch; list zeigt sie; remove räumt auf.
- Lohnt sich für parallele Features/Fixes, lang laufende Aufgaben neben anderer Arbeit und isolierte riskante Experimente.
- Hüte dich vor dem Merge-Back, teile keine zustandsbehafteten Ressourcen (DB, Port) über Worktrees hinweg und räume immer auf — und denk daran, dass Worktrees mit Subagenten zusammenspielen.