Sie sind drei Dateien tief in einem Feature-Branch, noch nichts committet, als ein Kollege wegen eines Null-Pointer-Crashs in Produktion anklopft. Der übliche Weg: git stash, zu main wechseln, den Fehler fixen, pushen, dann git stash pop – und hoffen, dass nichts in Ihrer halbfertigen Feature-Arbeit von den Dateien abhing, von denen Sie gerade weggewechselt sind. git worktree macht dieses Hin-und-Her überflüssig: Es checkt den Hotfix-Branch in einen zweiten Ordner aus, neben Ihrem Feature-Branch, beide auf Basis desselben Repositorys.

Was git worktree wirklich macht

Ein normaler Checkout gibt Ihnen die Dateien eines Branches auf einmal. Beim Wechseln des Branches werden diese Dateien an Ort und Stelle überschrieben. git worktree gibt Ihnen mehrere Checkouts desselben Repositorys, jeden in seinem eigenen Verzeichnis mit seinem eigenen Branch, und Sie bearbeiten sie unabhängig voneinander.

Das sind keine separaten Clones. Es gibt genau ein .git-Verzeichnis mit der Objektdatenbank, den Refs und der Konfiguration, und jeder Worktree liest und schreibt darauf. In einem zweiten Worktree ist .git nicht einmal ein Verzeichnis: Es ist eine einzeilige Datei, die auf das gemeinsame .git-Verzeichnis zurückverweist. Deshalb ist das Anlegen eines Worktrees fast augenblicklich, ohne dass zusätzliche Historie auf der Festplatte landet.

Eine Einschränkung zählt: Zwei Worktrees können nicht denselben Branch gleichzeitig ausgecheckt haben, denn ein Branch zeigt auf genau einen aktuellen Commit, und zwei Checkouts, die darauf committen, würden sich um diesen Zeiger streiten. Alles andere ist pro Worktree getrennt, von nicht verfolgten Dateien und dem Index bis zu dem Commit, auf dem HEAD steht.

Wie Sie einen Worktree für einen Hotfix anlegen

Aus Ihrem bestehenden Checkout von myapp heraus, auf feature/checkout-flow mit nicht committeten Änderungen:

1

git worktree add ../myapp-hotfix -b hotfix/null-pointer main

Das legt ../myapp-hotfix neben Ihrem aktuellen Verzeichnis an, mit einem neuen Branch hotfix/null-pointer, der von main abzweigt und im neuen Ordner ausgecheckt ist. Ihr ursprüngliches Verzeichnis bleibt auf feature/checkout-flow, unverändert mit seinen offenen Änderungen.

1
2
3
4

cd ../myapp-hotfix
# Bug fixen, committen, pushen
git push -u origin hotfix/null-pointer
cd ../myapp

Zurück im ursprünglichen Verzeichnis ist Ihre Feature-Arbeit genau so, wie Sie sie verlassen haben. Nichts zu poppen, kein Stash, den Sie vergessen könnten.

Ohne -b benennt git worktree add <Pfad> den Branch nach dem letzten Bestandteil des Pfads. Existiert noch kein Branch mit diesem Namen, legt Git ihn ausgehend von HEAD an; existiert er bereits und ist in keinem anderen Worktree ausgecheckt, checkt Git ihn aus. Nutzen Sie -d (--detach), wenn Sie nur einen Commit zum Herumschauen wollen, ganz ohne Branch.

Wie Sie Worktrees auflisten, entfernen und aufräumen

1

git worktree list

1
2

/home/user/myapp          3a1f9c2 [feature/checkout-flow]
/home/user/myapp-hotfix   7e04d81 [hotfix/null-pointer]

Sobald der Hotfix gemerged ist, entfernen Sie den Worktree über Git, statt den Ordner einfach zu löschen:

1

git worktree remove ../myapp-hotfix

remove verweigert sich, wenn der Worktree veränderte verfolgte Dateien oder nicht verfolgte Dateien enthält. Mit -f erzwingen Sie es trotzdem. Verschwindet das Verzeichnis auf anderem Weg (ein versehentliches rm -rf, ein abgestürzter CI-Job), behält Git seinen internen Eintrag, und git worktree list zeigt den Worktree weiterhin an. Den veralteten Eintrag entfernen Sie mit:

1

git worktree prune

Führen Sie es zuerst mit -n aus, um zu sehen, was entfernt würde.

Manche Worktrees sollen wochenlang bestehen bleiben: ein langlebiger Release-Branch, oder ein Checkout auf einem Netzlaufwerk, das nicht immer eingehängt ist. Sperren Sie diese, damit prune ihren Eintrag unangetastet lässt und move sowie remove sich weigern, sie zu berühren:

1
2

git worktree lock --reason "release branch, do not prune" ../myapp-release
git worktree unlock ../myapp-release

Entsperren Sie zuerst, wenn Sie einen Worktree mit git worktree move <Pfad> <neuer-Pfad> verschieben wollen. Einen gesperrten Worktree ohne Entsperren zu verschieben oder zu entfernen, braucht --force zweimal – als bewusste Ausnahme.

Wann Sie git worktree außer bei Hotfixes einsetzen

Immer dann, wenn Sie zwei aktive Checkouts statt einem brauchen:

  • Einen PR reviewen, ohne Ihre eigene Stelle zu verlieren. git worktree add ../myapp-review origin/some-pr-branch gibt Ihnen eine baubare Kopie des fremden Branches, während Ihre eigene Arbeit dort ausgecheckt bleibt, wo sie war.
  • git bisect laufen lassen, ohne alles andere zu blockieren. Ein Bisect bewegt HEAD bei jedem Schritt, sodass der Checkout, in dem es läuft, bis zum Abschluss oder Reset für alles andere unbrauchbar ist. Führen Sie es in einem eigenen Worktree aus (siehe Git Bisect: den Commit finden, der einen Bug eingeführt hat) und arbeiten Sie in Ihrem Haupt-Worktree normal weiter.
  • Zwei Jobs parallel gegen das Repository laufen lassen. Eine lange Test-Suite auf einem Branch, während Sie an einem anderen arbeiten, oder zwei KI-Coding-Agenten an getrennten Aufgaben: Jeder braucht sein eigenes Arbeitsverzeichnis. Ein Worktree liefert eines, ohne einen zweiten git clone und einen zweiten, mehrere Gigabyte großen .git-Ordner.

Wann git worktree nicht das richtige Werkzeug ist

Jeder Worktree dupliziert den Working Tree, nicht die Objektdatenbank. Zehn Worktrees eines Repositorys mit einem 50-MB-Checkout kosten auf der Festplatte rund 500 MB an Dateien, selbst mit nur einem .git. Für einen fünfminütigen Kontextwechsel ist git stash günstiger und hinterlässt nichts zum Aufräumen.

Submodule sind der Schwachpunkt. git worktree move verschiebt keinen Worktree, der Submodule enthält, und ein neuer Worktree startet mit leeren Submodul-Verzeichnissen, bis Sie darin git submodule update --init ausführen. Die Git-Dokumentation selbst bezeichnet die Submodul-Unterstützung in mehreren Checkouts als unvollständig; für ein Superprojekt mit vielen Submodulen ist ein separater Clone deshalb die sicherere Wahl.

Manche Tools gehen außerdem von genau einem Arbeitsverzeichnis pro Repository aus. Eine IDE oder ein File-Watcher, der seinen Cache am absoluten Repo-Pfad festmacht, kann durch dieselbe Historie an zwei Stellen verwirrt werden. Jeden Worktree als eigenes Projekt zu öffnen, statt als Unterordner des ersten, behebt das meist.

Wenn Sie in dem Checkout, den Sie schon haben, nur etwas zurückstellen oder rückgängig machen müssen, ist git stash oder git reset, revert oder restore das leichtere Werkzeug. Landet der nächste Hotfix mitten in einer Feature-Arbeit, probieren Sie git worktree add vor git stash aus und sehen Sie, welchen der beiden Sie danach lieber aufräumen.

Verwandte Artikel