Git Worktree: mehrere Branches gleichzeitig auschecken
Git-Worktree-Anleitung
Git Worktree: add, list, remove und prune mit Beispielen | We.Inc
Erstelle den genauen git worktree add Befehl für einen neuen Branch, einen bestehenden Branch oder einen Detached Commit und nutze dann list, lock, move, remove und prune sicher.
Mit git worktree kann ein Repository mehrere Arbeitsordner haben, jeder auf seinem eigenen Branch, die sich einen einzigen Objektspeicher teilen. Führe git worktree add ../hotfix -b hotfix aus, um einen neuen Ordner auf einem neuen Branch anzulegen, git worktree list, um alle zu sehen, und git worktree remove ../hotfix, wenn du fertig bist. Ein zweiter Klon ist nicht nötig.
Die Worktree-Befehle, die du im Alltag brauchst
Aufgabe
Befehl
Neuer Ordner auf einem neuen Branch
git worktree add ../app-fix -b fix/login
Neuer Ordner auf einem bestehenden Branch
git worktree add ../app-review feature/cart
Wegwerfordner bei einem Commit
git worktree add --detach ../app-old v1.4.0
Alle Worktrees anzeigen
git worktree list
Einen Worktree löschen
git worktree remove ../app-fix
Von Hand gelöschte Ordner aufräumen
git worktree prune
Jedes Mal zu stashen, zu wechseln und neu zu bauen, wenn jemand nach einem schnellen Fix fragt, kostet Zeit. Ein Worktree gibt dir einen zweiten Checkout desselben Repos in einem anderen Ordner, sodass ein langer Testlauf, ein Code-Review und ein dringender Patch jeweils in ihrem eigenen Verzeichnis leben können. Hol dir die Befehle mit dem Generator und sieh in der Referenz nach den selteneren Unterbefehlen.
Gib den gewünschten Ordner und den Branch-Namen ein und wähle neuer Branch, bestehender Branch oder Detached Commit.
Kopiere den add-Befehl und führe ihn in deinem Haupt-Checkout aus.
Arbeite im neuen Ordner wie in einem Klon: Committe, pushe und pulle dort.
Wenn der Branch gemergt ist, führe den remove-Befehl aus, den der Generator anzeigt, und nutze prune, falls du einmal einen Ordner von Hand gelöscht hast.
Lege Worktrees als Nachbarordner an, zum Beispiel ../app-fix, damit sie nie im Verzeichnisbaum des Haupt-Checkouts landen.
Jeder Worktree braucht eigene installierte Abhängigkeiten und eigene Build-Ausgaben. Plane den Speicherplatz für node_modules in jedem Ordner ein.
Ein Branch kann immer nur in einem Worktree gleichzeitig ausgecheckt sein. Wenn add sich weigert, sieh in git worktree list nach, wo er bereits geöffnet ist.
Sperre einen Worktree auf einem Wechseldatenträger mit git worktree lock --reason "usb disk", damit prune ihn nicht entfernt, solange das Laufwerk abgesteckt ist.
Häufige Fragen
Was ist der Unterschied zwischen einem Worktree und einem Klon?
Ein Klon kopiert das ganze Repository inklusive Historie. Ein verknüpfter Worktree teilt sich die Objekte und Refs des ursprünglichen Repositorys und fügt nur einen neuen Arbeitsordner plus ein paar Metadaten hinzu, sodass Commits aus einem Worktree in den anderen sofort sichtbar sind, ohne Fetch.
Können zwei Worktrees denselben Branch nutzen?
Standardmäßig nicht. git worktree add lehnt einen Branch ab, der bereits woanders ausgecheckt ist, weil zwei Ordner, die denselben Branch bewegen, gegenseitig ihre Arbeit überschreiben würden. --force hebt das auf, aber ein Detached HEAD oder ein zweiter Branch ist fast immer die bessere Wahl.
Warum schlägt git worktree remove fehl?
Der Befehl verweigert den Dienst, wenn der Ordner geänderte versionierte oder nicht versionierte Dateien enthält, damit du keine Arbeit verlierst. Committe oder bereinige den Ordner zuerst oder übergib --force. Ein gesperrter Worktree braucht --force zweimal.
Was macht git worktree prune?
Der Befehl löscht die übrig gebliebenen Einträge, die Git für Worktrees speichert, deren Ordner nicht mehr existieren, zum Beispiel nachdem du einen mit rm -rf entfernt hast. Mit -n siehst du vorher, was entfernt würde.
Wie benenne ich einen Worktree-Ordner um oder verschiebe ihn?
Nutze git worktree move <worktree> <new-path>, damit Git seine Einträge aktualisiert. Wenn du ihn schon mit dem Dateimanager verschoben hast, führe am neuen Ort git worktree repair aus, um ihn wieder zu verbinden.
Gute Gründe für Worktrees
Einen Pull Request prüfen, ohne halb fertige Arbeit zu stören, eine langsame Testsuite auf einem Branch laufen lassen, während du auf einem anderen programmierst, und zwei Versionen einer App nebeneinander vergleichen: Das sind die klassischen Fälle.
Sie eignen sich auch für Tools, die mehrere Coding-Sitzungen auf einem Repository ausführen: Jede Sitzung bekommt ihren eigenen Ordner und Branch, sodass nicht committete Dateien einer Sitzung nie in den Build einer anderen geraten.
Was geteilt wird und was nicht
Alle Worktrees teilen sich Commits, Branches, Tags, Remotes und den Großteil der Konfiguration. Jeder hat seinen eigenen HEAD, Index und eigene Arbeitsdateien, sodass Staging in einem Ordner die anderen nicht beeinflusst.
Ignorierte Dateien wie .env, node_modules und Build-Ordner werden nicht in einen neuen Worktree kopiert. Kopiere die Env-Datei selbst hinüber und installiere die Abhängigkeiten, bevor du etwas ausführst.