Git erlaubt seit Langem, mehrere Arbeitskopien an ein einziges Repository zu hängen, jede auf ihrem eigenen Branch und in ihrem eigenen Verzeichnis. Der Befehl git worktree erspart es, stash-Einträge zu stapeln, um zwischen Aufgaben zu springen, und ein ganzes Projekt neu zu klonen, nur um eine schnelle Korrektur zu öffnen. Der Mechanismus ist stabil, in jeder aktuellen Git-Version vorhanden und zahlt sich weit über sehr große Repositories hinaus aus.
Das Problem, das Worktrees lösen
Das Szenario ist verbreitet: Ein Feature ist in Arbeit, der Arbeitsbaum ist unsauber, und eine dringende Korrektur trifft den Produktions-Branch. Die gewohnten Reflexe haben je ihren Preis. git stash legt die Arbeit beiseite, zwingt aber zum Jonglieren mit einem unsichtbaren Stapel und trennt weder installierte Abhängigkeiten noch Build-Artefakte. Ein voller Neuklon dupliziert die gesamte Historie und verbraucht Speicher für ein lokal bereits vorhandenes Repository.
Ein Worktree bietet einen dritten Weg: ein zusätzliches Verzeichnis, an das bestehende Repository angehängt, das einen anderen Branch trägt. Die laufende Arbeit bleibt in ihrem Verzeichnis unversehrt, die Korrektur öffnet daneben, und beide bestehen nebeneinander, ohne sich in die Quere zu kommen.
Ein Branch pro Verzeichnis, eine einzige Historie: Der Kontextwechsel kostet keinen Stash mehr.
Einen Worktree anlegen, auflisten, verorten
Ein Worktree entsteht mit einem Befehl, aus einem bestehenden Branch oder indem er nebenbei erzeugt wird. Das erste Argument ist der Pfad des neuen Verzeichnisses, das zweite der Branch, der hineingelegt wird.
# Einen Worktree für einen bestehenden Branch hinzufügen
git worktree add ../paiement-hotfix hotfix/paiement
# Den Branch zusammen mit dem Worktree anlegen
git worktree add -b correctif-tva ../correctif-tva main
# Die an das Repository angehängten Worktrees auflisten
git worktree listDas Hauptverzeichnis bleibt der Standard-Worktree; die anderen kommen hinzu. git worktree list zeigt Pfad, aktuellen Commit und zugehörigen Branch und gibt einen sofortigen Überblick über die offenen Baustellen.
Was geteilt wird und was nicht
Alle Worktrees eines Repositories teilen sich ein einziges .git-Verzeichnis: Historie, Objekte, Branches und Remotes sind gemeinsam. Ein in einem Worktree gemachter Commit ist sofort aus den anderen sichtbar, ohne push oder fetch. Genau dieses Teilen macht den Vorgang gegenüber einem Clone speichergünstig.
Jeder Worktree hat hingegen eigene Arbeitsdateien, einen eigenen Index und ein eigenes HEAD. Was außerhalb von Gits Nachverfolgung liegt, wandert nicht mit: installierte Abhängigkeiten (etwa node_modules), ignorierte Umgebungsdateien und Build-Artefakte sind je Verzeichnis eigen. Das ist ein Vorteil, denn ein in einem Worktree laufender Build überschreibt nicht den eines anderen, bedeutet aber, die Abhängigkeiten in jedem neuen Verzeichnis neu zu installieren.
| Kriterium | git stash | Neuer Clone | git worktree |
|---|---|---|---|
| Gleichzeitige Arbeitskopien | Nein | Ja | Ja |
| Gemeinsame Historie und Objekte | Ja | Nein (dupliziert) | Ja |
| Speicherkosten | Keine | Hoch | Gering (nur Arbeitsdateien) |
| Isolierte Abhängigkeiten und Build | Nein | Ja | Ja |
| Kontextwechsel | Ablegen / holen | Ordner wechseln | Ordner wechseln |
Konkrete Anwendungsfälle
Die dringende Korrektur ist das Lehrbuchbeispiel, doch das Werkzeug dient mehreren weiteren Alltagsroutinen:
- Code-Review: Den Branch eines Pull Requests in einem eigenen Worktree auszuchecken, erlaubt, ihn wirklich zu starten, zu testen und zu vergleichen, ohne die laufende Arbeit zu stören.
- Lange Builds: Eine teure Kompilierung oder Testsuite kann in einem Worktree laufen, während die Entwicklung in einem anderen weitergeht.
- Bisect: Eine Regression mit
git bisectin einem separaten Worktree einzugrenzen, hält den Haupt-Arbeitsbaum sauber. - Versionen vergleichen: Zwei Branches nebeneinander offen halten, um zwei Umsetzungen derselben Seite oder API abzuwägen.
Für Freelancer mit mehreren Mandaten ist der Nutzen deutlich: Ein Kunden-Repository kann den abgerechneten Feature-Branch und die dringend verlangte Produktionskorrektur parallel halten, ohne Vermischung und ohne Neuklon.
Nützliche Details für den Alltag
Ein paar Punkte helfen, den Mechanismus voll auszuschöpfen. In einem sekundären Worktree ist das .git kein Verzeichnis, sondern eine einfache Datei, die auf das Haupt-Repository verweist: Dieser Verweis verschafft Zugang zur geteilten Historie. Da Konfiguration und Hooks im gemeinsamen Repository liegen, gelten sie für jeden Worktree, was die Umgebungen ohne manuelles Kopieren vereinheitlicht.
Drei Befehle runden das Werkzeug ab. git worktree add --detach legt ein Verzeichnis im Detached-Zustand an, praktisch für einen Wegwerf-Test ohne neuen Branch. git worktree move verschiebt einen bestehenden Worktree an einen anderen Pfad. git worktree lock schützt einen, der auf einem Wechselmedium oder einem Netzlaufwerk liegt, damit prune ihn während einer Abwesenheit nicht entfernt. Auf Editorseite ist die Logik unmittelbar: Jeder Worktree öffnet sich als eigenständiger Projektordner, mit eigenem Fenster und eigenem Terminal.
Bleibt die Frage des Orts. Worktrees in einem Geschwisterverzeichnis des Projekts oder in einem eigenen Ordner abzulegen, der die Kopien eines Repositories bündelt, hält den Baum lesbar und vermeidet, einen Worktree in einen anderen zu schachteln. Da Remotes geteilt werden, aktualisiert ein aus einem beliebigen Worktree gestartetes git fetch die Referenzen für alle und spart wiederholte Netzwege. Diese Ersparnis, auf einem kleinen Projekt unsichtbar, wird auf einem schweren Repository spürbar, wo jeder zusätzliche Clone Minuten und Gigabyte kosten würde.
Aufräumen und Fallen umgehen
Ist der Branch zusammengeführt, wird der Worktree sauber entfernt. Das Verzeichnis von Hand zu löschen, hinterlässt verwaiste Referenzen, die git worktree prune beseitigt.
# Einen Worktree entfernen, sobald der Branch zusammengeführt ist
git worktree remove ../paiement-hotfix
# Referenzen auf von Hand gelöschte Worktrees aufräumen
git worktree pruneDrei Fallen, die man kennen sollte. Derselbe Branch kann nicht in zwei Worktrees zugleich ausgecheckt werden: Git verweigert es, um zwei divergierende Historien auf derselben Referenz zu vermeiden. Abhängigkeiten und ignorierte Dateien werden nicht geteilt, also in jedem Verzeichnis neu installieren. Und relative Pfade sowie Skripte, die eine feste Projektwurzel voraussetzen, können überraschen, wenn der Worktree anderswo im Baum liegt.
Was bleibt
Worktrees schlagen das Duo aus Stash plus Neuklon, sobald zwei Kontexte gleichzeitig offen sein müssen. Sie teilen die Historie, um leicht zu bleiben, isolieren die Arbeitsdateien, um Kollisionen zu vermeiden, und werden mit drei Befehlen bedient: add, list, remove. Die Gewohnheit, die sich lohnt, ist das Aufräumen fertiger Verzeichnisse, damit keine vergessenen Arbeitskopien herumliegen.
In meinen Freelance-Mandaten haben Worktrees den lästigsten Fall gelöst: eine Produktionskorrektur, die mitten in ein halb geschriebenes Feature fällt. Kein Stash mehr, den man drei Tage später wiederfinden muss, keine node_modules mehr, die falsch herum neu kompiliert werden. Ein Verzeichnis pro Kontext, und der Kopf bleibt frei. Der einzige Reflex, den man sich aneignen muss, ist das remove: ohne es sammeln sich Phantom-Worktrees, die man sich am Ende nicht mehr anzufassen traut — Simon Janvier
Weiterführend
Git — Offizielle git-worktree-Dokumentation
