Zum Inhalt springen
Tooling

Git Worktrees: Parallel an mehreren Branches arbeiten

8 min Lesezeit
Git Workflow Produktivitaet

Jeder kennt das Szenario: Du steckst mitten in einem Feature, hast fuenf Dateien offen, ein paar temporäre Debug-Statements eingebaut — und dann kommt die Nachricht: “Kannst du kurz den PR reviewen?” oder “Auf Production ist ein Bug”. Was folgt, ist der Stash-Dance: git stash, Branch wechseln, arbeiten, zurückwechseln, git stash pop, hoffen dass nichts kaputt ist. Das ist nicht nur nervig, es ist fehleranfaellig.

Git Worktrees lösen dieses Problem grundlegend. Und trotzdem nutzen sie die wenigsten.

Das Problem: Context Switching mit Git ist teuer

Der klassische Workflow bei einem Branch-Wechsel sieht so aus:

  1. Änderungen stashen (und hoffen, dass der Stash sauber ist)
  2. Branch wechseln
  3. Dependencies neu installieren, falls sich package-lock.json geändert hat
  4. Build-Cache ist möglicherweise invalide
  5. IDE re-indexiert das Projekt
  6. Aufgabe erledigen
  7. Zurück zum urspruenglichen Branch
  8. Stash poppen, Dependencies nochmal prüfen

Das kostet nicht nur Zeit, sondern mentalen Kontext. Wer zwischen drei Branches hin- und herspringt, verliert den Überblick. Und git stash list mit fuenf namenlosen Einträgen hilft auch nicht weiter.

Was git worktree tatsächlich macht

Ein Worktree ist ein zusätzliches Working Directory, das mit demselben Repository verknüpft ist. Alle Worktrees teilen sich die gleiche .git-Datenbank — Commits, Branches, Refs, alles. Aber jeder Worktree hat seinen eigenen Checkout, seine eigene Staging Area und seinen eigenen HEAD.

Das bedeutet: Du kannst mehrere Branches gleichzeitig ausgecheckt haben, in separaten Verzeichnissen, ohne das Repository zu klonen. Kein doppelter Speicherverbrauch für die Git-Objekte, kein Sync-Problem zwischen Kopien.

Grundlagen: add, list, remove

Die API ist erfreulich simpel. Drei Befehle decken 90% der Anwendungsfaelle ab.

Worktree erstellen und verwalten bash 
# Neuen Worktree für einen existierenden Branch erstellen
git worktree add ../project-review feature/auth-refactor

# Neuen Worktree mit neuem Branch erstellen
git worktree add -b fix/login-bug ../project-hotfix main

# Alle Worktrees auflisten
git worktree list
# /home/david/project          abc1234 [main]
# /home/david/project-review   def5678 [feature/auth-refactor]
# /home/david/project-hotfix   abc1234 [fix/login-bug]

# Worktree entfernen (nach getaner Arbeit)
git worktree remove ../project-hotfix

# Verwaiste Worktrees aufraeumen (Verzeichnis manuell geloescht)
git worktree prune

Die Konvention, Worktrees als Geschwister-Verzeichnisse anzulegen (../project-review), hat sich bewaehrt. So bleibt die Projektstruktur übersichtlich und die IDE-Konfiguration im Hauptverzeichnis unberuehrt.

Reale Anwendungsfaelle

PR-Review ohne Kontextverlust

Der häufigste Fall: Du arbeitest an Feature A, sollst aber den PR für Feature B reviewen. Mit Worktrees oeffnest du den PR-Branch in einem separaten Verzeichnis, startest dort den Dev-Server, testest — und dein Feature-A-Branch bleibt exakt so, wie du ihn verlassen hast.

PR-Review-Workflow mit Worktrees bash 
# PR-Branch in separatem Verzeichnis auschecken
git fetch origin pull/42/head:pr-42
git worktree add ../project-pr-42 pr-42

# In den Worktree wechseln, Dependencies installieren, testen
cd ../project-pr-42
npm install
npm run dev

# Nach dem Review: aufraeumen
cd ../project
git worktree remove ../project-pr-42
git branch -d pr-42

Hotfix parallel zur Feature-Entwicklung

Production-Bug, aber dein Feature-Branch hat uncommittete Änderungen und einen halben Refactor? Kein Problem. Worktree vom main-Branch erstellen, Hotfix implementieren, pushen, Worktree entfernen. Der Feature-Branch wurde nie angefasst.

Implementierungen vergleichen

Manchmal will man zwei Ansaetze parallel ausprobieren. Mit Worktrees kann man beide Varianten gleichzeitig offen haben, den Code direkt nebeneinander vergleichen und den Dev-Server für beide laufen lassen — auf verschiedenen Ports.

Integration mit IDE und Tooling

Die meisten IDEs können mit Worktrees umgehen, ohne zusätzliche Konfiguration. VS Code oeffnet einfach den Worktree-Ordner als neues Fenster. JetBrains-IDEs erkennen die Git-Verknüpfung automatisch.

Ein paar Punkte, die den Workflow glaetten:

  • Terminal-Multiplexer (tmux, Zellij): Ein Pane pro Worktree. Ctrl-B + 1 für Feature, Ctrl-B + 2 für Review.
  • Shell-Aliases: Worktree-Erstellung mit sinnvollen Defaults automatisieren.
  • direnv: Pro Worktree unterschiedliche .envrc-Dateien für Environment-Variablen.
Shell-Aliases für schnelles Worktree-Management bash 
# In .bashrc oder .zshrc
alias gwa='git worktree add'
alias gwl='git worktree list'
alias gwr='git worktree remove'

# Funktion: Worktree für PR-Review erstellen
gw-review() {
  local pr_number=$1
  git fetch origin "pull/${pr_number}/head:pr-${pr_number}"
  git worktree add "../$(basename $(pwd))-pr-${pr_number}" "pr-${pr_number}"
  echo "Worktree erstellt: ../$(basename $(pwd))-pr-${pr_number}"
}

# Funktion: Alle Worktrees aufraeumen
gw-clean() {
  git worktree list --porcelain | grep "^worktree " | tail -n +2 | \
    sed 's/^worktree //' | while read wt; do
      read -p "Worktree $wt entfernen? [y/N] " answer
      [[ "$answer" == "y" ]] && git worktree remove "$wt"
  done
}

Stolpersteine und Einschraenkungen

Worktrees sind kein Allheilmittel. Es gibt ein paar Dinge, die man wissen sollte:

Gleicher Branch, nur einmal ausgecheckt. Git verhindert, dass derselbe Branch in mehreren Worktrees gleichzeitig ausgecheckt ist. Das ist Absicht — andernfalls waeren inkonsistente Zustände unvermeidlich. Wer trotzdem denselben Stand braucht, erstellt einen temporären Branch oder arbeitet mit detached HEAD.

Shared Refs können ueberraschen. Ein git reset --hard in einem Worktree verschiebt den Branch-Pointer für alle Worktrees. Wer in Worktree A den Branch develop auf einen aelteren Commit zurücksetzt, sieht das auch in Worktree B, wenn dort develop referenziert wird.

Submodules sind problematisch. Submodules und Worktrees vertragen sich schlecht. Die Submodule-Verzeichnisse werden nicht automatisch in neue Worktrees uebernommen. Wer viele Submodules nutzt, muss manuell nachhelfen oder auf git worktree add mit anschliessendem git submodule update --init setzen.

Node Modules und Build-Artefakte. Jeder Worktree braucht seine eigenen node_modules. Das bedeutet ein npm install pro Worktree. Bei großen Projekten mit vielen Dependencies summiert sich der Speicherverbrauch. Tools wie pnpm mit globalem Store mildern das Problem.

Fortgeschritten: Das Bare-Repo-Pattern

Der eleganteste Worktree-Workflow basiert auf einem Bare Repository als Zentrale. Statt ein normales Repository zu klonen und dort Worktrees hinzuzufügen, klont man das Repo als bare und erstellt für jeden Branch einen eigenen Worktree — inklusive main.

Bare-Repo-Pattern einrichten bash 
# Repository als bare klonen
git clone --bare git@github.com:user/project.git project.git

cd project.git

# Remote-Tracking konfigurieren (nötig bei bare Clones)
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
git fetch origin

# Worktrees für die Branches erstellen
git worktree add ../project-main main
git worktree add ../project-develop develop
git worktree add ../project-feature-x feature/x

# Ergebnis:
# project.git/           (bare repo, keine Working Copy)
# project-main/          (main Branch)
# project-develop/       (develop Branch)
# project-feature-x/     (feature/x Branch)

Der Vorteil dieses Patterns: Es gibt kein “Haupt”-Working-Directory, das bevorzugt behandelt wird. Alle Branches sind gleichwertig, jeder in seinem eigenen Verzeichnis. Das mentale Modell ist klarer — man arbeitet nicht “in einem Repo mit Worktrees”, sondern hat ein Repo mit mehreren gleichberechtigten Arbeitsverzeichnissen.

Dieser Ansatz eignet sich besonders für Projekte, an denen man regelmäßig zwischen mehreren langlebigen Branches arbeitet. Die initiale Einrichtung ist etwas aufwändiger, aber der tägliche Workflow wird dadurch deutlich fluessiger.

Fazit

Git Worktrees lösen ein echtes Problem: den Reibungsverlust beim Wechsel zwischen Branches. Kein Stashing, kein Cache-Invalidieren, kein mentaler Kontextverlust. Die API ist minimal, die Integration mit bestehenden Tools unkompliziert.

Wer regelmäßig PR-Reviews macht, Hotfixes auf Production bearbeitet oder mehrere Features parallel entwickelt, sollte Worktrees eine Woche lang im Alltag testen. Die Wahrscheinlichkeit, danach zum Stash-Dance zurückzukehren, ist gering.

Zurück zum Blog