Wer an einer Webapp arbeitet, kennt das Problem: Ein Bugfix muss schnell in einen Release-Branch, während parallel ein Feature-Branch offen ist. Ständiges Wechseln per Checkout wirkt zunächst einfach, sorgt aber oft für Reibung: uncommitted Änderungen, kaputte lokale Builds oder das berühmte „Nur kurz stashen“.
Genau hier hilft Git Worktree. Statt im selben Ordner ständig den Branch zu wechseln, entstehen zusätzliche Arbeitsordner (Worktrees), die auf dasselbe Repository zeigen. So können mehrere Branches parallel offen sein – sauber getrennt und trotzdem effizient.
Git Worktree: Was es ist und warum es im Alltag hilft
Ein Worktree ist ein zusätzliches Arbeitsverzeichnis für ein bereits geklontes Git-Repository. Technisch bleibt es dasselbe Repository (mit derselben .git-Verwaltung), nur der „Working Tree“ (die ausgecheckten Dateien) liegt in einem weiteren Ordner.
Praktisch bedeutet das: Ein Branch bleibt im Hauptordner geöffnet, ein anderer Branch liegt in einem zweiten Ordner. Beide lassen sich gleichzeitig bearbeiten, starten, testen oder builden – ohne dass Dateien beim Wechseln verschwinden oder sich gegenseitig beeinflussen.
Typische Situationen, in denen Worktrees Zeit sparen
- Parallel Development: Feature-Branch entwickeln und gleichzeitig Hotfix im Release-Branch testen.
- Code-Review lokal nachvollziehen: Pull-Request-Branch in einem separaten Ordner auschecken.
- Mehrere Versionen laufen lassen: z. B. alte und neue API-Version parallel starten.
- Große Builds vermeiden: Branch-Wechsel triggert oft Neuinstallationen; getrennte Ordner reduzieren Chaos.
Worktrees einrichten: die wichtigsten Befehle mit Beispiel
Voraussetzung: Ein bestehendes Git-Repository, in dem bereits gearbeitet wird. Dann lassen sich weitere Worktrees hinzufügen.
Neuen Worktree für einen bestehenden Branch anlegen
Beispiel: Der Branch feature/login soll in einem zweiten Ordner liegen.
git worktree add legt den Ordner an und checkt den Branch dort aus:
git worktree add ../app-login feature/login
Danach gibt es zwei Ordner nebeneinander, z. B. app (main) und app-login (feature/login). In beiden Ordnern kann unabhängig gearbeitet werden.
Neuen Branch direkt als Worktree erstellen
Wenn der Branch noch nicht existiert, kann er beim Anlegen gleich erzeugt werden:
git worktree add -b feature/onboarding ../app-onboarding
Das ist besonders praktisch für neue Features, weil der Branch und das Arbeitsverzeichnis in einem Schritt entstehen.
Aktive Worktrees anzeigen und entfernen
Welche Worktrees aktuell registriert sind, zeigt:
git worktree list
Ein Worktree wird wieder entfernt, wenn er nicht mehr gebraucht wird:
git worktree remove ../app-login
Wichtig: Entfernen löscht den zusätzlichen Arbeitsordner, nicht das Repository und nicht den Branch (sofern er noch existiert).
Sauber arbeiten: typische Stolperfallen (und wie sie lösbar sind)
Worktrees wirken simpel, aber ein paar Details entscheiden darüber, ob das Setup langfristig angenehm bleibt.
„Warum kann ich den Branch nicht im zweiten Ordner auschecken?“
Ein Branch kann immer nur in genau einem Worktree gleichzeitig ausgecheckt sein. Das ist Absicht: Sonst könnten zwei Ordner denselben Branch mit unterschiedlichen lokalen Änderungen enthalten – Chaos wäre vorprogrammiert.
Wenn ein Branch bereits in einem Worktree hängt, gibt es zwei saubere Optionen:
- Den Worktree nutzen, in dem der Branch schon ausgecheckt ist (Pfad über git worktree list finden).
- Einen neuen Branch für die zweite Arbeit erstellen (z. B. feature/login-test), statt denselben Branch doppelt zu öffnen.
Build-Artefakte und node_modules: getrennt halten
Bei JavaScript-Projekten ist node_modules oft der größte Zeitfresser. Ein Worktree hat einen eigenen Ordnerstand, also auch eigene Abhängigkeiten. Das ist zunächst „mehr Speicher“, verhindert aber Seiteneffekte (z. B. wenn zwei Branches unterschiedliche Lockfiles haben).
Tipps für den Alltag:
- Abhängigkeiten pro Worktree installieren (sauber, aber doppelt).
- Wenn möglich, Package-Manager nutzen, die Caches verwenden (beschleunigt Installationen).
- Build-Ausgaben im Projekt konsequent ignorieren (gitignore), damit Worktrees nicht „schmutzig“ werden.
Uncommitted Änderungen: Worktrees ersetzen nicht Disziplin
Worktrees reduzieren das Bedürfnis, ständig zu stashen – aber sie ersetzen keine sauberen Commits. Gerade bei Hotfixes hilft eine klare Trennung:
- Hotfix-Worktree: nur Änderungen für den Fix.
- Feature-Worktree: Feature-Änderungen ohne Mischmasch.
Wer häufig in Situationen kommt, in denen temporär geparkt werden muss, kann ergänzend den Artikel Git Stash verstehen – Änderungen sicher parken und zurückholen nutzen.
Wann Worktrees besser sind als Checkout, Stash oder mehrere Klone
Ein Worktree ist nicht immer die beste Wahl. Die Entscheidung hängt davon ab, was parallel passieren soll und wie schwergewichtig das Projekt ist.
| Ansatz | Gut, wenn … | Weniger gut, wenn … |
|---|---|---|
| Branch wechseln (checkout/switch) | nur kurz vergleichen, keine parallelen Builds nötig | häufige Kontextwechsel, uncommitted Änderungen, lange Buildzeiten |
| Stash | kleine Unterbrechung, späteres Weiterarbeiten im selben Branch | viele Stashes, unklare Zuordnung, Risiko beim Anwenden/Drop |
| Mehrere Klone | vollständig getrennte Umgebungen nötig | doppelte Remotes/Configs, mehr Pflege, mehr Speicher |
| Worktrees | zwei bis drei Branches wirklich parallel laufen sollen | sehr viele parallele Kontexte (dann wird es unübersichtlich) |
Eine kleine Entscheidungshilfe für den Alltag
- Wenn nur schnell ein anderer Branch geprüft werden soll: Branch wechseln.
- Wenn eine Unterbrechung kommt und später im selben Branch weitergeht: Stash oder Commit auf WIP-Branch.
- Wenn zwei Branches gleichzeitig laufen müssen (Server/Tests/Builds): Worktree.
- Wenn komplett andere Tooling-Versionen gebraucht werden: separater Klon oder Container-Setup.
Praxis-Setup: Hotfix und Feature parallel, ohne Chaos
Ein häufiges Szenario: Ein Bug im Release-Branch muss gefixt werden, während ein Feature schon in Arbeit ist. Mit Worktrees bleibt beides getrennt.
Beispielablauf
- Im Hauptordner läuft das Feature weiter (z. B. feature/onboarding).
- Ein zweiter Ordner wird für den Release-Branch angelegt.
- Hotfix wird dort umgesetzt, getestet und sauber committet.
- Feature bleibt unberührt und muss nicht gestasht werden.
Dazu passt auch ein sauberer Umgang mit Commits: Git Commit Messages schreiben – klare Historie im Team hilft, Hotfixes später schnell zu finden.
So bleibt das Worktree-Setup wartbar
Worktrees sind besonders angenehm, wenn sie nicht „wild wachsen“. Mit ein paar Regeln bleibt es übersichtlich.
Kleine „So klappt’s“-Box für den Alltag
- Worktrees neben das Hauptprojekt legen (z. B. ../app-hotfix), nicht tief verschachteln.
- Ordnernamen nach Zweck benennen (app-pr-123, app-hotfix, app-release).
- Regelmäßig prüfen: git worktree list zeigt alte Worktrees.
- Worktrees entfernen, wenn der Branch gemerged ist: git worktree remove.
- Bei Merge-Konflikten bewusst bleiben: Konflikte entstehen durch Git, nicht durch Worktrees. Hilfreich ist Git Merge Conflicts lösen – sauber arbeiten ohne Chaos.
Häufige Fragen aus der Praxis
Kann ein Worktree eigene Git-Einstellungen haben?
Worktrees teilen sich das Repository, also auch viele Einstellungen. Branch-spezifische Dinge (z. B. Konfiguration über lokale Hooks oder Tooling) sollten daher eher im Projekt selbst gelöst werden, nicht „pro Ordner“. Für stark unterschiedliche Setups sind separate Klone oder Container oft die klarere Lösung.
Funktioniert Worktree mit Submodulen?
Ja, aber Submodule erhöhen die Komplexität, weil zusätzliche Repositories im Spiel sind. Wenn Submodule genutzt werden, lohnt sich ein sauberer Workflow. Dazu passt Git Submodule verstehen – Abhängigkeiten sauber verwalten.
Ist das auch für Einsteiger sinnvoll?
Ja, wenn der Grund klar ist: paralleles Arbeiten ohne Branch-Wechsel-Stress. Wer gerade erst Git lernt, sollte zuerst Branches, Commits und Merges sicher beherrschen. Danach ist Worktree eine sehr praktische Erweiterung, weil es typische Alltagsprobleme entschärft, statt neue zu schaffen.
