Git Worktree gezielt für lokale Code-Reviews nutzen

1. Das Problem mit Branch-Wechseln bei parallelen Reviews

Ein schnelles Review zwischendurch bedeutet klassischerweise: eigene Änderungen mit git stash beiseitelegen, auf den zu prüfenden Branch wechseln, den Code sichten und anschließend wieder zurückwechseln und den Stash erneut anwenden. Bei einer einzelnen, kurzen Unterbrechung ist das noch handhabbar, bei mehreren parallelen Reviews am selben Tag summiert sich der Aufwand jedoch spürbar.

Störender als der reine Zeitaufwand ist häufig der Nebeneffekt auf laufende Prozesse: Ein Dev-Server, ein Watcher für Tailwind-CSS-Builds oder ein laufender Docker-Container arbeiten in der Regel auf dem aktuell ausgecheckten Stand des Arbeitsverzeichnisses. Ein Branch-Wechsel mittendrin bringt diese Prozesse aus dem Takt oder erfordert einen kompletten Neustart, sobald wieder zum eigenen Branch zurückgewechselt wird.

2. Was ein Git Worktree ist und wie es sich vom Klonen unterscheidet

Ein Git Worktree ist ein zusätzliches Arbeitsverzeichnis, das denselben internen .git-Datenspeicher wie das ursprüngliche Repository nutzt, aber einen eigenen, unabhängigen Checkout eines bestimmten Branches im Dateisystem bereitstellt. Objekte, Commits und Konfiguration werden dabei nicht dupliziert, sondern gemeinsam genutzt, wodurch ein zusätzlicher Worktree im Vergleich zu einem vollständigen weiteren Klon des Repositorys kaum zusätzlichen Speicherplatz benötigt.

Im Unterschied zu einem vollständigen zweiten Klon bleiben Worktrees eng miteinander verbunden: Ein neuer Commit, der in einem Worktree entsteht, ist sofort auch im Hauptrepository und in allen anderen Worktrees als Referenz sichtbar, ganz ohne dass zwischen den Verzeichnissen erst gepusht und wieder gefetcht werden müsste.

3. Einen Review-Worktree für einen Pull-Request-Branch anlegen

Der Befehl git worktree add nimmt einen Zielpfad und optional einen Branch-Namen entgegen und richtet daraus einen vollständigen, eigenständigen Checkout ein. Existiert der angegebene Branch bereits lokal, wird er genau dort ausgecheckt, existiert er nur remote, checkt Git ihn automatisch als neuen lokalen Tracking-Branch im neuen Verzeichnis aus.

Für ein Review reicht damit ein einziger Befehl: Ein neues Verzeichnis neben dem Hauptrepository entsteht, der zu prüfende Branch ist dort vollständig ausgecheckt, und der eigene Arbeitsstand im Hauptverzeichnis bleibt währenddessen komplett unberührt, inklusive aller nicht committeten Änderungen und laufender Hintergrundprozesse.

# Neuen Worktree für einen bestehenden Feature-Branch anlegen
git worktree add ../review-checkout-redesign feature/checkout-redesign

# Neuen Worktree für einen nur remote existierenden Branch anlegen
git worktree add ../review-pricing-fix origin/fix/pricing-rounding

4. Bestehende Remote-Branches gezielt in einem Worktree auschecken

Für Reviews von Pull Requests aus GitHub oder GitLab lässt sich der zugehörige Remote-Branch direkt beim Anlegen des Worktrees referenzieren, ohne vorher manuell in das Hauptrepository fetchen und dort einen lokalen Branch anlegen zu müssen. Ein einziger git fetch gefolgt von git worktree add reicht meist aus, um einen einreichten Branch vollständig lokal verfügbar zu machen.

Bei Projekten, die die GitHub- oder GitLab-CLI verwenden, lässt sich dieser Schritt zusätzlich vereinfachen: gh pr checkout checkt einen Pull-Request-Branch direkt aus, und in Kombination mit einem vorbereiteten Worktree-Verzeichnis bleibt der eigentliche Review-Workflow trotzdem vollständig vom laufenden Arbeitsstand getrennt.

# Aktuellen Stand aller Remote-Branches holen und dann einen Worktree anlegen
git fetch origin
git worktree add ../review-pr-142 origin/feature/pr-142

5. Mehrere Worktrees verwalten: list, lock und remove

Mit steigender Zahl paralleler Reviews lohnt sich ein regelmäßiger Blick auf git worktree list, das alle aktuell existierenden Worktrees inklusive Pfad und ausgechecktem Branch übersichtlich auflistet. Das erleichtert es, den Überblick zu behalten, welches Verzeichnis welchem Review-Vorgang zugeordnet ist, gerade wenn mehrere Pull Requests gleichzeitig geprüft werden.

Für Worktrees auf externen oder gelegentlich getrennten Datenträgern verhindert git worktree lock, dass Git diesen Worktree bei internen Aufräumvorgängen fälschlich als verwaist einstuft und automatisch entfernt, solange der Datenträger vorübergehend nicht verbunden ist. Ist ein Review abgeschlossen, entfernt git worktree remove das Verzeichnis wieder sauber, inklusive der zugehörigen internen Referenz im Hauptrepository.

# Alle aktuell existierenden Worktrees mit Pfad und Branch anzeigen
git worktree list

# Abgeschlossenen Review-Worktree sauber entfernen
git worktree remove ../review-pr-142

6. Worktrees mit dem IDE-Workflow kombinieren

Da jeder Worktree ein eigenständiges Verzeichnis im Dateisystem ist, lässt sich in PhpStorm oder einer vergleichbaren IDE für jeden Review-Vorgang ein eigenes Projektfenster öffnen, komplett unabhängig vom Hauptprojektfenster mit dem eigenen Arbeitsstand. Ein Review-Kommentar, der Sprung zu einer Definition oder ein probeweise gestarteter Test läuft dadurch stets im richtigen Kontext, ohne versehentlich den eigenen Branch zu beeinflussen.

Für Magento- oder Hyvä-Projekte mit eigenem Docker-Setup bedeutet das zusätzlich, dass ein separates Compose-Setup oder ein eigener Datenbank-Container gezielt für den Review-Worktree gestartet werden kann, während die gewohnte Entwicklungsumgebung im Hauptverzeichnis unbeeinflusst weiterläuft.

7. Aufräumen: gelöschte Worktrees und verwaiste Referenzen entfernen

Wird ein Worktree-Verzeichnis versehentlich manuell über das Dateisystem gelöscht, statt über git worktree remove, bleibt im Hauptrepository zunächst eine verwaiste interne Referenz zurück, die bei einer erneuten Auflistung als fehlerhaft markiert erscheint. git worktree prune räumt genau solche verwaisten Referenzen auf, indem es prüft, welche referenzierten Verzeichnisse tatsächlich noch existieren, und entfernt alle übrigen Einträge automatisch.

Ein regelmäßiges, gelegentliches git worktree prune ist besonders bei einem hohen Durchsatz an kurzlebigen Review-Worktrees sinnvoll, damit die interne Verwaltungsstruktur des Repositorys nicht unnötig mit Verweisen auf längst nicht mehr existierende Verzeichnisse anwächst.

# Verwaiste Referenzen auf manuell gelöschte Worktree-Verzeichnisse entfernen
git worktree prune

8. Grenzen und Stolperfallen von Worktrees im Review-Alltag

Ein und derselbe Branch lässt sich nicht gleichzeitig in zwei verschiedenen Worktrees auschecken, Git verhindert das gezielt, um widersprüchliche gleichzeitige Änderungen an ein und demselben Branch zu vermeiden. Für parallele Reviews unterschiedlicher Branches ist das kein Problem, wohl aber, wenn versehentlich zweimal derselbe Branch geöffnet werden soll.

Außerdem teilen sich alle Worktrees eines Repositorys dieselbe zugrunde liegende Objektdatenbank, weshalb aggressive, destruktive Operationen wie git gc --aggressive oder ein manuelles Löschen von Objekten im Hauptrepository theoretisch auch andere Worktrees betreffen können. In der alltäglichen Review-Praxis mit reinen Lese- und Test-Operationen tritt dieses Risiko jedoch praktisch nie auf.

9. Vergleich zu stash-basiertem Kontextwechsel

Der klassische Ablauf aus git stash, Branch-Wechsel und späterem git stash pop bleibt für sehr seltene, einmalige Unterbrechungen weiterhin eine legitime, einfache Option, gerade wenn ohnehin kein zweites Verzeichnis angelegt werden soll. Sobald Reviews jedoch regelmäßig vorkommen oder mehrere Branches gleichzeitig offen bleiben sollen, überwiegen die Vorteile eines dedizierten Worktrees klar.

Der entscheidende Unterschied liegt darin, dass ein Worktree den eigenen Arbeitsstand überhaupt nicht berührt: Kein Stash, der versehentlich vergessen wird, kein Risiko eines Stash-Konflikts beim späteren Zurückwechseln, und kein Neustart laufender Entwicklungsprozesse. Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen.

10. Zusammenfassung

11. FAQ: Worktree für Reviews