git worktree: in mehreren Branches gleichzeitig arbeiten

Was git worktree macht

git worktree verbindet mehrere Arbeitsverzeichnisse mit einem einzigen Repository. Im Hauptordner haben Sie Ihren Feature-Branch ausgecheckt, im Nachbarordner main für einen dringenden Hotfix – und beide existieren gleichzeitig. Objekte, Commits und Branches werden geteilt: Ein Commit in einem Ordner ist im anderen sofort sichtbar, ohne push und fetch.

Ohne worktree sieht ein Kontextwechsel so aus: git stash, git switch main, Fix, git switch zurück, git stash pop. Hat das Projekt einen langen Build oder ein schweres node_modules, macht jeder Branch-Wechsel zusätzlich Caches ungültig. Die zweite Option – das Repository erneut klonen – liefert zwei unabhängige Kopien der Historie, die Sie über den Remote-Server synchron halten müssen.

Worktree vereint das Beste aus beiden Ansätzen: getrennte Ordner, aber eine gemeinsame .git-Datenbank. Das funktioniert, weil ein Branch in Git nur ein Zeiger auf einen Commit ist und keine Kopie von Dateien – nichts hindert verschiedene Arbeitskopien daran, auf verschiedene Zeiger zu schauen.

Zusätzliche Arbeitskopie anlegen

Die Grundform des Befehls: git worktree add <pfad> [<branch>]. Hier die wichtigsten Varianten.

Vorhandenen Branch öffnen

cd ~/projects/shop
git worktree add ../shop-main main
Preparing worktree (checking out 'main')
HEAD is now at 3f2c1ab README aktualisieren

Neben dem Projekt erscheint der Ordner shop-main mit dem Branch main. Wechseln Sie mit einem normalen cd hinein und arbeiten Sie wie in jedem anderen Repository.

Neuen Branch direkt mit Arbeitskopie anlegen

git worktree add -b hotfix/payment-timeout ../shop-hotfix main

Das Flag -b erstellt den Branch hotfix/payment-timeout von main und öffnet ihn im neuen Ordner. -B macht dasselbe, setzt einen bereits vorhandenen Branch aber auf den angegebenen Commit zurück – gehen Sie damit vorsichtig um.

Kurzform

git worktree add ../experiment

Geben Sie keinen Branch an, erstellt Git einen neuen Branch mit dem Namen der letzten Pfadkomponente (hier experiment) vom aktuellen HEAD. Existiert bereits ein Branch dieses Namens, wird er geöffnet.

Arbeitskopie ohne Branch

git worktree add --detach ../shop-v1.4 v1.4.0

Der Modus detached HEAD eignet sich, um ein altes Release anhand eines Tags zu bauen oder zu prüfen, ohne überflüssige Branches anzulegen.

Branch vom Remote-Server

git fetch origin
git worktree add ../review-auth feature/auth

Gibt es keinen lokalen Branch feature/auth, aber genau einen Remote-Branch origin/feature/auth, legt Git einen lokalen Tracking-Branch an – wie bei git switch feature/auth. So reviewen Sie bequem einen fremden Pull Request, ohne Ihre eigene Arbeit anzufassen.

Arbeitskopien anzeigen und entfernen

git worktree list
/home/anna/projects/shop            a1b2c3d [feature/cart]
/home/anna/projects/shop-hotfix     7e8f9a0 [hotfix/payment-timeout]
/home/anna/projects/shop-v1.4       5d6e7f8 (detached HEAD)

Die erste Zeile ist die Haupt-Arbeitskopie (main worktree), die übrigen sind verknüpfte (linked) Arbeitskopien. Für Skripte gibt es die maschinenlesbare Ausgabe git worktree list --porcelain.

Ist der Hotfix gemergt, entfernen Sie die Arbeitskopie:

git worktree remove ../shop-hotfix
git branch -d hotfix/payment-timeout

git worktree remove löscht den Ordner und die internen Einträge. Enthält die Kopie nicht committete Änderungen oder nicht versionierte Dateien, verweigert der Befehl die Arbeit; fügen Sie --force nur hinzu, wenn Sie sicher sind, dass sie nicht mehr gebraucht werden. Beachten Sie: Der Branch selbst wird dabei nicht gelöscht, das erledigen Sie separat.

Wenn der Ordner von Hand gelöscht wurde

Wer den Ordner im Dateimanager oder per rm -rf löscht, hinterlässt in .git/worktrees einen verwaisten Eintrag, und der Branch gilt weiterhin als belegt. Räumen Sie solche Einträge auf:

git worktree prune --verbose

Git erledigt das bei der Garbage Collection gelegentlich auch selbst, warten müssen Sie darauf aber nicht.

Wie es intern funktioniert

In einer verknüpften Arbeitskopie gibt es statt des Ordners .git eine Datei .git mit einer einzigen Zeile:

gitdir: /home/anna/projects/shop/.git/worktrees/shop-hotfix

In diesem internen Ordner liegen die Daten, die nur zu dieser Arbeitskopie gehören: ein eigener HEAD, ein eigener Index (Staging Area), eigene merge- und rebase-Zustände. Alles andere wird geteilt: Objekte, Branches, Tags, Remotes, Konfiguration und Hooks.

Aus der Tabelle folgt ein nicht offensichtliches Detail: git stash list zeigt in jeder Kopie dieselben Einträge. Das ist sogar praktisch – Sie können Änderungen in einem Ordner stashen und im anderen wieder hervorholen.

Die wichtigste Einschränkung: ein Branch – eine Arbeitskopie

Denselben Branch können Sie nicht in zwei Arbeitskopien öffnen. Versuchen Sie es, antwortet Git mit einem Fehler wie diesem:

git worktree add ../shop-copy feature/cart
fatal: 'feature/cart' is already used by worktree at '/home/anna/projects/shop'

(in älteren Git-Versionen lautet der Text „is already checked out at“). Die Einschränkung verhindert, dass ein Commit in einem Ordner den Branch im anderen stillschweigend unter den Füßen verändert. Lösungen: einen neuen Branch vom selben Commit anlegen (-b), die Kopie im Modus --detach öffnen oder – wenn es unbedingt sein muss – --force verwenden und die Folgen bedenken.

Aus demselben Grund funktioniert git switch main im Hauptordner nicht, solange main in einer anderen Arbeitskopie geöffnet ist.

Praxisszenarien

Dringender Hotfix mitten in einem Feature

git worktree add -b hotfix/null-price ../shop-hotfix main
cd ../shop-hotfix
# beheben, testen
git commit -am "Absturz bei leerem Preis beheben"
git push -u origin hotfix/null-price
cd ../shop
git worktree remove ../shop-hotfix

Ihr unfertiges Feature bleibt unverändert, nichts musste in den stash, und die IDE mit dem geöffneten Projekt hat vom Wechsel nicht einmal etwas mitbekommen.

Pull-Request-Review mit Ausführen des Codes

Eine eigene Kopie für das Review erlaubt es, einen fremden Branch zu bauen, zu starten und die Tests laufen zu lassen – während Sie im Nachbarfenster des Editors an Ihrer eigenen Aufgabe weiterarbeiten.

Verhalten zweier Versionen vergleichen

Zwei Kopien mit unterschiedlichen Tags lassen sich parallel auf verschiedenen Ports starten, um etwa die Antwortzeit einer API vor und nach einer Optimierung zu vergleichen.

Lange Tests und Builds

Starten Sie den kompletten Testlauf in einer Kopie und schreiben Sie in der anderen weiter Code – der Build geht nicht kaputt, weil Sie Dateien ändern.

Mehrere KI-Agenten parallel

Arbeiten mehrere Agenten oder Prozesse an Aufgaben, bekommt am besten jeder eine eigene Arbeitskopie auf einem eigenen Branch: Sie kommen sich nicht in die Quere, und die Ergebnisse landen sofort im gemeinsamen Repository.

Ordnerstruktur bei regelmäßiger Arbeit mit worktree

Wenn Sie Arbeitskopien täglich brauchen, legen Sie eine feste Struktur fest, sonst verwandeln sich die Nachbarverzeichnisse schnell in eine Müllhalde. Ein beliebtes Schema: ein übergeordneter Projektordner mit einem Bare-Repository darin und je einem Ordner pro Branch:

git clone --bare git@example.com:team/shop.git ~/projects/shop/.bare
cd ~/projects/shop
echo "gitdir: ./.bare" > .git
git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
git fetch origin

git worktree add main
git worktree add -b feature/cart feature-cart main

Die Zeile mit remote.origin.fetch ist nötig, weil ein Bare-Klon standardmäßig kein Tracking der Remote-Branches einrichtet. Am Ende liegen in ~/projects/shop die Ordner main und feature-cart, jeder mit eigenem Branch, und keiner ist „wichtiger“ als der andere.

Eine zweite gute Gewohnheit: den Ordner so zu benennen wie den Branch (Schrägstrich durch Bindestrich ersetzt). Dann ist an der Ausgabe von git worktree list und am Pfad im Terminal immer klar, wo Sie sich befinden. Und schließlich: Entfernen Sie die Kopie direkt nach dem Merge des Branches – alte Arbeitskopien belegen Speicherplatz und halten Branches „belegt“.

Typische Fehler und Stolperfallen

• Abhängigkeiten und Build werden nicht geteilt. Jede Kopie ist ein eigener Ordner, daher müssen node_modules, die Python-Virtualenv, .env und Build-Artefakte neu angelegt werden. Nicht versionierte Dateien werden nicht in die neue Kopie übernommen.
• Arbeitskopie innerhalb des Hauptordners. git worktree add ./hotfix legt einen Ordner im Projekt an, und die Haupt-Arbeitskopie sieht ihn als nicht versionierte Dateien. Legen Sie Kopien daneben (../) oder in einem eigenen Verzeichnis ab, oder tragen Sie den Pfad in .gitignore ein.
• Ordner von Hand verschoben. Die Verknüpfung bricht. Verschieben Sie mit git worktree move ../old ../new; ist es schon passiert, führen Sie im neuen Ordner git worktree repair aus.
• Kopie auf einem Wechseldatenträger verschwindet. Damit prune den Eintrag einer Kopie auf einem getrennten Laufwerk nicht entfernt, sperren Sie sie: git worktree lock --reason "externes Laufwerk" ../shop-usb.
• Submodule. Die Unterstützung von Submodules in Arbeitskopien ist eingeschränkt; führen Sie nach dem Anlegen einer Kopie git submodule update --init aus und prüfen Sie das Ergebnis.

Spickzettel zu git worktree

git worktree, stash oder zweiter Klon?

Für kurze Unterbrechungen von ein paar Minuten bleibt stash die beste Wahl. Für alles, was länger dauert, oder wenn zwei Versionen gleichzeitig offen sein sollen, ist worktree bequemer.

Fazit

git worktree ist ein einfacher Weg, mit mehreren Branches gleichzeitig zu arbeiten: add legt einen Ordner an, list zeigt sie an, remove und prune räumen auf. Die Historie ist gemeinsam, HEAD, Index und Dateien hat jede Kopie für sich; ein Branch kann nicht in zwei Kopien geöffnet sein. Wie Branches aufgebaut sind und warum der Wechsel zwischen ihnen so leichtgewichtig ist, behandeln wir ausführlich und praxisnah im Git-Kurs.