Paralleles Arbeiten mit git worktrees statt Stash-und-Switch

Ziel

Gleichzeitig an zwei oder mehr Branches arbeiten, jeder in einem eigenen Verzeichnis mit eigenem Build-Zustand, ohne erneut zu klonen und ohne wiederholtes Stashen und Wechseln.

Voraussetzungen

Ein Git-Repository (dessen Checkout ist der „Haupt-Worktree"). Speicherplatz für zusätzliche Checkouts. Werkzeuge, die keinen einzelnen Repository-Pfad fest verdrahten: Editor-Projekte, virtuelle Umgebungen, Build-Verzeichnisse.

Schritte

1. Einen Worktree für einen bestehenden Branch erstellen: git worktree add ../repo-review feature/x. Für einen neuen Branch: git worktree add -b fix/login ../repo-fix. Die Dokumentation weist darauf hin, dass git worktree add <path> allein einen Branch erstellt, der nach der letzten Pfadkomponente benannt ist, und dass -d einen Wegwerf-Checkout mit losgelöstem HEAD erzeugt.
2. Im neuen Verzeichnis wie in jedem Checkout arbeiten. Die Dokumentation beschreibt den neuen Baum als einen „verknüpften Worktree" (linked worktree), der alles mit dem Repository teilt ausser worktree-spezifischen Dateien wie HEAD und dem Index; Refs unter refs/ werden geteilt, Pseudo-Refs wie HEAD sind je Worktree eigenständig.
3. Alles einrichten, was die Werkzeuge ausserhalb von git halten: Abhängigkeitsinstallationen, .env-Kopien, Build-Verzeichnisse. Nicht versionierte Dateien werden zwischen Worktrees nicht geteilt.
4. Mit git worktree list auflisten, was existiert (--porcelain für Skripte). git weigert sich, einen Worktree für einen Branch zu erstellen, der bereits anderswo ausgecheckt ist, sofern nicht --force angegeben wird; daher einen Branch pro Worktree verwenden.
5. Nach Abschluss: git worktree remove ../repo-fix (weigert sich bei einem unsauberen Baum, sofern nicht erzwungen), dann den Branch löschen, falls gemergt. Wurde ein Verzeichnis von Hand gelöscht, entfernt git worktree prune die veralteten Verwaltungsdateien; git worktree repair verbindet Bäume neu, die verschoben wurden.
6. Für Einstellungen, die sich je Worktree unterscheiden müssen, extensions.worktreeConfig aktivieren und git config --worktree verwenden, wie die Dokumentation beschreibt.

Erwartetes Ergebnis

Mehrere Verzeichnisse, jedes auf seinem eigenen Branch, die sich einen Objektspeicher und einen Satz Remotes teilen; der Kontextwechsel ist ein cd, und ein langer Testlauf in einem Worktree blockiert keine Bearbeitungen in einem anderen.

Grenzen und Prüfbasis

Die Semantik folgt der zitierten git-worktree-Dokumentation. Worktrees, die Submodule enthalten, können nicht mit git worktree move verschoben werden. Da alles ausser worktree-spezifischen Dateien geteilt wird, gelten Hooks und Repository-Konfiguration für alle Worktrees. Werkzeuge, die nach Pfad cachen (Language Server, Container-Mounts, IDE-Indizes), brauchen unter Umständen eine separate Konfiguration, und der Speicherbedarf wächst mit jedem Worktree. Es wird keine Leistungsmessung behauptet.