Ein Hotfix trifft oft genau dann ein, wenn der aktuelle Feature-Branch noch nicht für einen Commit bereit ist. Statt Änderungen zwischenzuspeichern oder einen zweiten Klon anzulegen, kannst du mit Git Worktree einen weiteren Branch in einem eigenen Ordner öffnen.
So bleibt die laufende Aufgabe unverändert liegen, während du den Fehler separat untersuchst. Beide Arbeitsverzeichnisse gehören zum selben Repository, haben aber jeweils einen eigenen Branch und Git-Status.
Wann Git Worktree die bessere Abkürzung ist
Stell dir vor, du arbeitest an einer überarbeiteten Bestellstrecke. Mehrere Dateien sind geändert, eine Migration ist noch nicht fertig und der aktuelle Zwischenstand soll bewusst nicht committed werden. Nun sollst du einen Fehler auf Basis von main prüfen und beheben.
Mit einem klassischen Branchwechsel müsstest du deine Änderungen zuerst sichern. Ein Stash funktioniert technisch, verlangt später aber Kontextarbeit: Welcher Stash gehört zu welcher Aufgabe? Wurde auch eine unversionierte Datei erfasst? Lässt sich der Stand konfliktfrei zurückholen? Der Stash ist praktisch, aber kein Zwischenlager mit Inventarsystem.
Ein zweiter Klon trennt die Aufgaben ebenfalls, benötigt jedoch zusätzlichen Speicherplatz und eine getrennte lokale Konfiguration. Ein Worktree liegt dazwischen: Du erhältst ein separates Arbeitsverzeichnis, während Git die gemeinsame Repository-Basis weiterverwendet.
Git Worktree passt vor allem zu diesen Situationen:
- Du musst einen Hotfix bearbeiten, während dein aktueller Branch unfertig ist.
- Du möchtest einen Pull Request lokal prüfen, ohne deine laufende Arbeit wegzupacken.
- Du brauchst zwei Versionen eines Projekts gleichzeitig, etwa für einen direkten Vergleich.
- Ein Prozess läuft in einem Branch weiter, während du in einem anderen Branch arbeitest.
Für einen kurzen Branchwechsel bei sauberem Arbeitsverzeichnis bleibt git switch meist ausreichend. Worktrees lohnen sich, sobald die getrennten Arbeitsstände für eine Weile parallel bestehen sollen.
Wie ein Worktree aufgebaut ist
Dein bisheriger Projektordner bleibt der primäre Worktree. Weitere Worktrees sind zusätzliche Verzeichnisse, die mit demselben Repository verbunden werden. Jeder Worktree besitzt einen eigenen ausgecheckten Stand, einen eigenen Index und eine eigene HEAD-Position. Der Index ist der Bereich, in dem Git vorgemerkte Änderungen für den nächsten Commit verwaltet.
Commits und Branches gehören weiterhin zum gemeinsamen Repository. Wenn du im Hotfix-Worktree einen Commit erstellst, kennt ihn deshalb auch dein ursprünglicher Worktree. Deine nicht committed Dateien werden dagegen nicht zwischen den Ordnern übertragen.
Eine wichtige Schutzregel ist eingebaut: Git verhindert normalerweise, dass derselbe Branch gleichzeitig in mehreren Worktrees ausgecheckt wird. Damit reduziert Git das Risiko, dass zwei Arbeitsverzeichnisse unabhängig denselben Branch verschieben. Die vollständigen Befehle und Sonderfälle beschreibt die offizielle Dokumentation zu Git Worktree.
Einen Hotfix-Worktree anlegen
Im folgenden Beispiel liegt das bestehende Projekt im Ordner shop. Deine unfertige Arbeit bleibt dort geöffnet. Für den Hotfix legst du daneben den Ordner shop-hotfix an.
- Prüfe zuerst, wo du stehst. Das ist keine Voraussetzung für den Worktree, verhindert aber Verwechslungen beim späteren Aufräumen.
git status
git branch --show-currentDu musst die angezeigten Änderungen weder committen noch stashen. Sie bleiben im bestehenden Arbeitsverzeichnis.
- Aktualisiere die Referenzen des Remote-Repositorys. So basiert der neue Hotfix-Branch auf dem aktuellen Stand von origin/main.
git fetch origin- Erstelle den Worktree und den Hotfix-Branch.
git worktree add -b hotfix/payment-timeout ../shop-hotfix origin/mainDer Parameter -b erstellt den neuen Branch hotfix/payment-timeout. ../shop-hotfix ist das zusätzliche Arbeitsverzeichnis. origin/main legt den Ausgangspunkt fest. Verwendet dein Projekt einen anders benannten Hauptbranch, musst du den Befehl entsprechend anpassen.
- Öffne den neuen Ordner separat.
cd ../shop-hotfix
git statusIn diesem Verzeichnis kannst du den Fehler untersuchen, Änderungen committen und den Branch pushen. Dein ursprünglicher Projektordner bleibt auf dem Feature-Branch stehen – einschließlich aller lokalen Änderungen.
Lokale Projektdateien bewusst ergänzen
Ein neuer Worktree enthält die von Git verwalteten Dateien. Ignorierte lokale Dateien werden nicht automatisch aus deinem ursprünglichen Arbeitsverzeichnis kopiert. Dazu können eine .env-Datei, installierte Composer-Pakete, Node-Abhängigkeiten, Uploads oder lokale Datenbanken gehören.
Das ist kein Fehler, sondern eine sinnvolle Trennung. Prüfe nach dem Anlegen, welche lokalen Voraussetzungen das Projekt benötigt. Kopiere Konfigurationsdateien nicht blind. Ein Hotfix-Worktree braucht selten Produktionszugänge, nur weil sie im anderen Ordner zufällig vorhanden sind.
Auch parallel gestartete Anwendungen können sich in die Quere kommen. Zwei Instanzen dürfen beispielsweise nicht ohne weitere Anpassung denselben lokalen Port belegen. Für eine reine Codeänderung oder einen automatisierten Test ist das oft irrelevant. Wenn beide Versionen gleichzeitig laufen sollen, benötigen sie getrennte Ports oder Prozessnamen.
Vorhandene Worktrees kontrollieren
Mit folgendem Befehl siehst du alle verbundenen Arbeitsverzeichnisse, ihre Commits und die jeweils ausgecheckten Branches:
git worktree listDiese Übersicht ist nützlich, wenn mehrere Reviews oder Hotfixes parallel existieren. Benenne die Ordner deshalb nach ihrem Zweck. shop-hotfix oder shop-review-checkout bleiben verständlicher als shop-2-final-neu.
Einen bereits vorhandenen Branch kannst du ebenfalls in einem zusätzlichen Worktree öffnen:
git worktree add ../shop-hotfix hotfix/payment-timeoutDas funktioniert nur, wenn dieser Branch nicht schon in einem anderen Worktree ausgecheckt ist. Meldet Git an dieser Stelle einen Konflikt, solltest du zunächst mit git worktree list prüfen, wo der Branch verwendet wird, statt die Sperre zu umgehen.
Den Worktree sauber entfernen
Nach dem Merge des Hotfixes brauchst du das zusätzliche Arbeitsverzeichnis meist nicht mehr. Prüfe dort zuerst den Status:
cd ../shop-hotfix
git statusEnthält der Worktree noch relevante Änderungen, sichere oder committe sie. Wechsle anschließend in ein anderes Verzeichnis und entferne den Worktree über Git:
cd ../shop
git worktree remove ../shop-hotfixIst der Branch vollständig gemergt und wird nicht mehr benötigt, kannst du ihn danach löschen:
git branch -d hotfix/payment-timeoutLösche den zusätzlichen Ordner möglichst nicht einfach über den Dateimanager. Git behält sonst zunächst Verwaltungsdaten für einen Worktree, der auf der Festplatte nicht mehr existiert. Ist das versehentlich passiert, entfernt git worktree prune veraltete Verwaltungsinformationen.
Die Option –force beim Entfernen ist kein normaler Bestandteil des Ablaufs. Git verweigert das Entfernen eines Worktrees mit Änderungen aus gutem Grund. Prüfen dauert gewöhnlich kürzer als das spätere Rekonstruieren einer verlorenen Korrektur.
Worktree, Stash oder zweiter Klon?
Die Werkzeuge lösen ähnliche, aber nicht identische Aufgaben. Ein Stash eignet sich für eine kurze Unterbrechung, wenn du deinen aktuellen Arbeitsstand vorübergehend aus dem Weg räumen möchtest. Er hält jedoch keine zweite direkt nutzbare Projektumgebung bereit.
Ein Worktree ist sinnvoll, wenn zwei Branches gleichzeitig zugänglich bleiben sollen. Du kannst beide Ordner in getrennten Editorfenstern öffnen, Tests ausführen und zwischen den Aufgaben wechseln, ohne Änderungen ein- und auszupacken.
Ein separater Klon bleibt passend, wenn du eine vollständig unabhängige lokale Repository-Konfiguration brauchst, bewusst mit anderen Remotes arbeitest oder die Kopie langfristig getrennt verwalten möchtest. Für einen Hotfix während einer laufenden Aufgabe ist diese Trennung häufig größer als nötig.
Eine kleine Konvention verhindert neues Chaos
Git Worktree spart nur dann Kontextwechsel, wenn die zusätzlichen Ordner nachvollziehbar bleiben. Lege sie an einem festen Ort ab, benenne sie nach Aufgabe oder Branch und entferne sie nach Abschluss. Eine eigene Sammlung vergessener Worktrees wäre lediglich Stash-Chaos mit mehr Verzeichnissen.
Im Team genügt oft eine kurze Vereinbarung: Worktrees liegen neben dem primären Projektordner, der Ordnername beschreibt den Zweck und jeder Entwickler räumt seine lokalen Worktrees selbst auf. Die Worktrees selbst werden nicht geteilt oder committed.
Wenn häufige Unterbrechungen eher aus unklaren Aufgaben, zu vielen parallelen Tickets oder fehlenden Entscheidungen entstehen, löst ein Git-Befehl das organisatorische Problem allerdings nicht. Der Artikel über Mythen zur Entwickler-Produktivität ordnet solche breiteren Ursachen ein.
Fazit: Parallele Arbeit braucht getrennte Arbeitsstände
Git Worktree ist kein Ersatz für saubere Branches und auch kein Grund, beliebig viele Aufgaben gleichzeitig anzufangen. Das Werkzeug löst einen konkreten Fall: Du musst einen zweiten Branch vollständig bearbeiten, ohne den unfertigen Stand im ersten Arbeitsverzeichnis anzufassen.
Für Hotfixes, lokale Reviews und direkte Versionsvergleiche ist das meist übersichtlicher als ein Stash und schlanker als ein zweiter Klon. Der entscheidende Vorteil liegt nicht in einem kürzeren Befehl. Du behältst beide Arbeitskontexte sichtbar, getrennt und sofort nutzbar.
Häufige Fragen
Kurz beantwortet, damit du schneller einschätzen kannst, was für dein Projekt wichtig ist.
Kann ich denselben Branch in zwei Git-Worktrees öffnen?
Normalerweise nicht. Git sperrt einen bereits ausgecheckten Branch für weitere Worktrees, damit zwei Arbeitsverzeichnisse ihn nicht unabhängig verändern.
Werden nicht committe Änderungen in den neuen Worktree übernommen?
Nein. Jeder Worktree besitzt eigene Arbeitsdateien und einen eigenen Index. Nicht committe Änderungen bleiben ausschließlich in dem Worktree, in dem du sie erstellt hast.
Ist Git Worktree besser als Git Stash?
Das hängt von der Aufgabe ab. Für eine kurze Unterbrechung reicht ein Stash häufig aus. Wenn zwei Branches gleichzeitig nutzbar bleiben sollen, ist ein Worktree meist übersichtlicher.
Kann ich einen Git-Worktree einfach als Ordner löschen?
Verwende besser git worktree remove. Beim manuellen Löschen können Verwaltungsdaten im Repository zurückbleiben, die du anschließend mit git worktree prune bereinigen musst.
