Git-Worktrees: paralleles Arbeiten ohne den Verstand zu verlieren (und warum KI-Agenten sie lieben)

Eine einzige Kopie des Repositorys, viele unabhängige Arbeitsverzeichnisse: das Git-Feature, das meine Art, den Kontext zu wechseln, verändert hat.

Es gibt einen Moment im Alltag jedes Entwicklers, den du auswendig kennst. Du steckst tief in einem kniffligen Feature: zwölf geänderte Dateien, die IDE hat endlich alles neu indiziert, der Debugger steht an einem Breakpoint, dein Kopf hält ein extrem fragiles gedankliches Kartenhaus zusammen. Und genau in diesem Augenblick kommt die Nachricht: “Es gibt einen kritischen Bug in der Produktion, wir brauchen sofort einen Fix.”

Was tust du? Die klassischen Optionen sind drei, und alle drei tun weh. Du kannst git stash machen und beten, dass du dich erinnerst, was du gerade in der Hand hattest. Du kannst halbfertige Arbeit mit einer Nachricht wie WIP funktioniert noch nicht committen, die die History für immer verschmutzt. Oder du klonst das Repository erneut in einen anderen Ordner, wartest auf den Download, konfigurierst die Umgebung neu und baust alles von Grund auf neu. So oder so stürzt dieses gedankliche Kartenhaus ein.

Es gibt eine vierte Option, und seit ich sie entdeckt habe, nutze ich sie fast täglich: Git-Worktrees. Und hier komme ich zum eigentlichen Grund, warum ich diesen Beitrag geschrieben habe: Worktrees gibt es schon seit Jahren in Git, und trotzdem sehe ich immer wieder unzählige Entwickler, sogar hervorragende, die sie nicht nutzen und nicht einmal wissen, dass es sie gibt. Jedes Mal, wenn ich sie jemandem zeige, ist die Reaktion dieselbe: “Wie konnte ich bis heute nur ohne sie arbeiten?”. Also bringen wir die Sache ein für alle Mal in Ordnung: woher sie kommen, welches Problem sie wirklich lösen, wie man sie nutzt und warum sie heute auch für KI-basierte Coding-Agenten zu einem unverzichtbaren Werkzeug geworden sind.

Woher sie kommen

Der Befehl git worktree kam mit Git 2.5, veröffentlicht am 27. Juli 2015. Davor war die implizite Regel eisern: ein Repository, ein Arbeitsverzeichnis. Wolltest du an zwei Branches gleichzeitig in zwei verschiedenen Ordnern arbeiten, war der einzige offizielle Weg ein wiederholtes git clone, mit all der Verschwendung, die das mit sich bringt: doppelter Speicherplatz, erneut heruntergeladene Objekte, neu zu konfigurierende Remotes und keinerlei Verbindung zwischen den Kopien.

Worktrees haben diese Einschränkung gesprengt. Die zugrunde liegende Idee ist elegant: die History eines Repositorys (Commits, Branches, Tags, Objekte) existiert genau einmal in .git, während die Arbeitsverzeichnisse, die sie auf der Festplatte materialisieren, viele sein können. Eine einzige Quelle der Wahrheit, viele Arbeitstische, die darauf blicken.

Ein einziger Stamm (die gemeinsame History in .git), aus dem sich eine Krone unabhängiger Arbeitsverzeichnisse verzweigt. Genau so funktionieren Git-Worktrees.

Das Problem, das sie wirklich lösen

Das klassische Git-Modell hat einen präzisen Flaschenhals: es gibt nur ein Arbeitsverzeichnis, also kann es immer nur auf einem Branch gleichzeitig sein. git checkout (oder das modernere git switch) ist eine destruktive Operation auf deinem Workspace: es schreibt die Dateien auf der Festplatte um, damit sie den Ziel-Branch widerspiegeln. Daraus ergeben sich alle Ärgernisse, die du kennst.

• Nicht committete Änderungen stehen im Weg. Hast du schmutzige Dateien, weigert sich Git, den Branch zu wechseln, oder zwingt dich zum Stashen. Der Stash ist ein versteckter Stapel, auf dem man Dinge unglaublich leicht vergisst.
• Branch-Wechsel macht die Build-Arbeit zunichte. Du wechselst den Branch und die Zeitstempel der Dateien ändern sich: die IDE indiziert neu, der Compiler baut die halbe Lösung neu, der Test-Cache wird geleert. In einem Delphi-Projekt einer gewissen Größe oder in jeder großen Codebase bedeutet das Minuten, die bei jedem Sprung verloren gehen.
• Du kannst nicht zwei Branches im selben Moment ansehen. Willst du das Verhalten des Features mit main nebeneinander vergleichen? Mit einem einzigen Arbeitsverzeichnis geht das nicht: du musst hin und her springen und jedes Mal neu bauen.

Worktrees beseitigen den Flaschenhals an der Wurzel. Jeder Arbeitskontext bekommt seinen eigenen Ordner, mit seinen eigenen Dateien, seinem eigenen Build-Zustand, unabhängig von den anderen. Den Kontext zu wechseln wird zu einem cd, nicht zu einem git stash gefolgt von einem Rebuild.

Wie man sie nutzt: die vier Befehle, die du brauchst

Die gesamte Worktree-API passt in eine Handvoll Befehle. Gehen wir davon aus, dass du dich in einem bereits geklonten Repository befindest.

Einen Worktree erstellen auf einem bestehenden Branch, in einem Ordner neben dem Projektordner:

# Erstellt ../app-hotfix als Arbeitsverzeichnis, ausgecheckt auf Branch hotfix/login
git worktree add ../app-hotfix hotfix/login

Einen Worktree und einen neuen Branch zusammen erstellen, in einem Zug:

# Erstellt Branch feature/export ausgehend von main und gibt ihm seinen eigenen Ordner
git worktree add -b feature/export ../app-export main

Alle aktiven Worktrees auflisten, mit ihrem Pfad und dem Branch, auf dem sie stehen:

git worktree list
# /home/daniele/app           a1b2c3d [main]
# /home/daniele/app-hotfix    e4f5g6h [hotfix/login]
# /home/daniele/app-export    i7j8k9l [feature/export]

Einen Worktree entfernen, wenn du fertig bist, und übrig gebliebene verwaiste Referenzen aufräumen:

git worktree remove ../app-hotfix
git worktree prune   # räumt die Metadaten von Hand gelöschter Worktrees auf

Eine Anmerkung, die man sich gleich merken sollte: Git lässt dich nicht denselben Branch in zwei Worktrees gleichzeitig auschecken. Das ist ein gewollter Schutz, keine willkürliche Beschränkung. Zwei Ordner, die denselben Branch verändern, wären das perfekte Rezept, um durcheinanderzukommen und sich gegenseitig die Commits zu zertreten. Wenn du es wirklich brauchst, gibt es --force, aber in 99 % der Fälle bewahrt dich diese Fehlermeldung vor Ärger.

Es gibt auch ein paar weitere Befehle, die du seltener nutzt, von denen man aber wissen sollte, dass es sie gibt: git worktree move, um ein Arbeitsverzeichnis an einen anderen Pfad zu verschieben, git worktree lock / unlock, um zu verhindern, dass ein Worktree (zum Beispiel auf einem Wechseldatenträger oder einer Netzwerkfreigabe) automatisch aufgeräumt wird, und git worktree repair, um die Referenzen zu reparieren, wenn du Ordner von Hand verschoben hast und Git den Faden verloren hat. Für den täglichen Gebrauch decken die vier obigen Befehle jedoch alles ab.

Und wenn du die Maus der Tastatur vorziehst, bleibst du nicht außen vor: die reiferen grafischen Werkzeuge stellen Worktrees genauso selbstverständlich bereit. In Git Extensions gibt es zum Beispiel ein eigenes Untermenü unter Repository, Worktrees, mit Einträgen, um einen neuen zu erstellen und die bestehenden zu verwalten.

Worktrees aus Git Extensions erstellen und verwalten: keine Kommandozeile, nur ein Menü.

Ein Layout, das sich von selbst ordentlich hält

Wenn Worktrees ein fester Teil deines Workflows werden, macht sie ein kleiner Organisationstrick noch sauberer. Statt Ordner wahllos über die Festplatte zu verstreuen, ist eine sehr verbreitete Konvention, das Repository als bare in einen Ordner .bare zu klonen und alle Worktrees als Unterordner daneben zu halten, einen pro Branch:

git clone --bare git@github.com:benutzer/app.git app/.bare
cd app
echo "gitdir: ./.bare" > .git
# checkout der bestehenden Branches, jeder in seinem eigenen Ordner
git worktree add main main
git worktree add feature-export feature/export

So wird dein Projekt zu einem Ordner app/, der main/, feature-export/ und so weiter enthält, jeder einsatzbereit, mit der gemeinsamen History versteckt in .bare. Beachte, dass ich den Branch immer als zweites Argument übergebe: lässt du ihn weg, nimmt Git nur das letzte Pfadsegment als Branch-Namen (aus feature/export würde es export nehmen) und erstellt am Ende oft einen brandneuen Branch, selten den gemeinten. Es ist kein zwingendes Setup, aber wenn du mit vielen Worktrees arbeitest, dankst du es dir selbst.

Beispiele aus dem echten Leben

Die Theorie ist kurz, der Nutzen riesig. Hier sind die Szenarien, in denen ich einen Worktree öffne, ohne auch nur darüber nachzudenken.

Der Hotfix, während ein Feature halbfertig ist

Zurück zur Eingangsszene. Du bist mitten in feature/neuer-bericht, das Arbeitsverzeichnis voller Änderungen. Der Notfall trifft ein. Statt zu stashen:

git worktree add -b hotfix/crash-pdf ../app-hotfix main
cd ../app-hotfix
# hier behebst du den Bug, committest, pushst, öffnest den PR
# währenddessen bleibt dein Feature im anderen Ordner unangetastet

Ist das Feuer gelöscht, machst du cd zurück in den Feature-Ordner und findest alles genau so vor, wie du es verlassen hast: offene Dateien, Build-Zustand, Breakpoints. Null Stashes, null Rebuilds.

Das Code-Review, ohne die eigene Arbeit zu stören

Ein Kollege bittet dich, seinen PR zu reviewen. Du willst ihn wirklich ausführen, nicht nur das Diff auf einer Webseite lesen. Mit einem einzigen Arbeitsverzeichnis müsstest du deine Arbeit unterbrechen. Mit einem Worktree nicht:

git worktree add ../app-review feature/kollege-pr
cd ../app-review
# du baust, führst aus, probierst das Feature des Kollegen aus
# dein persönlicher Branch wird nicht einmal berührt

Ein langer Build parallel

Der klassische Fall in großen Projekten: ein vollständiger Build oder die Test-Suite dauert Minuten. Statt Däumchen zu drehen, startest du den schweren Build in einem Worktree und schreibst in einem anderen weiter Code. Zwei Ordner, zwei unabhängige Build-Zustände, keine Interferenz.

Der direkte Vergleich zweier Versionen

Musst du herausfinden, warum sich ein Verhalten zwischen main und dem Release-Branch geändert hat? Öffne zwei Worktrees, einen für jeden, und stelle sie buchstäblich nebeneinander in zwei Editor-Fenster. Kein Hin und Her: du siehst sie im selben Augenblick.

Warum KI-Agenten sie so intensiv nutzen

Hier werden Worktrees vom persönlichen Komfort zum Wegbereiter einer ganzen Arbeitsweise. KI-basierte Coding-Agenten wie Claude Code und Ähnliche haben einen natürlichen Appetit auf paralleles Arbeiten: mehrere Aufgaben gleichzeitig ausführen, jede ändert Dateien, startet Builds und committet eigenständig.

Das Problem ist, dass mehrere Instanzen, die im selben Arbeitsverzeichnis arbeiten, sich gegenseitig in die Quere kämen: ein Agent ändert eine Datei, während ein anderer sie gerade kompiliert, Branches werden überschrieben, der Zustand wird inkonsistent. Die Lösung, die diese Werkzeuge wählen, ist genau der Git-Worktree: jeder Agent oder jede parallele Aufgabe bekommt einen isolierten Worktree. Jeder hat seinen eigenen Ordner, seinen eigenen Branch, seinen eigenen Build-Zustand, aber alle teilen sich dieselbe Objektdatenbank, sodass es keine Duplizierung der History gibt und die Ergebnisse mit einem normalen Merge ins Haupt-Repository zurückfließen.

Es ist genau dasselbe Muster, das ich von Hand für einen Hotfix nutze, auf industrielle Skala gebracht und automatisiert. Ein Agent arbeitet an Feature A in ../app-feature-a, ein anderer an Feature B in ../app-feature-b, ein dritter führt die Tests in ../app-tests aus, und keiner der drei weiß auch nur von der Existenz der anderen. Die Isolation, die Worktrees für uns bequem macht, ist genau die Eigenschaft, die sie für die Orchestrierung mehrerer paralleler Agenten unverzichtbar macht.

Ein paar Vorsichtsmaßnahmen

Worktrees sind solide, aber ein paar Dinge sollte man wissen, bevor man sich die Finger verbrennt.

• Derselbe Branch, nur ein Worktree. Wir haben es gesagt: das ist ein Schutz, kein Mangel. Um denselben Branch an zwei Stellen zu testen, erstelle einen Hilfs-Branch.
• Die Konfiguration ist geteilt, das Arbeitsverzeichnis nicht. Worktrees teilen sich config, die Objekte und die Branches, aber jeder hat seinen eigenen HEAD, seinen eigenen Index und seine eigenen Dateien. Der Stash, Vorsicht, ist auf Repository-Ebene geteilt: stell ihn dir nicht an einen bestimmten Worktree gebunden vor.
• Räum auf. Wenn du einen Worktree-Ordner von Hand löschst statt mit git worktree remove, bleiben verwaiste Metadaten zurück: git worktree prune räumt sie auf. git worktree list ist dein Dashboard, um den Überblick nicht zu verlieren.
• Submodule brauchen Aufmerksamkeit. Nutzt das Projekt Submodule, denk daran, sie auch im neuen Worktree zu initialisieren; sie materialisieren sich nicht von selbst.

Kernpunkte

• Ein Repository, viele Arbeitsverzeichnisse. Git-Worktrees, eingeführt in Git 2.5 (Juli 2015), geben dir mehrere Arbeitsordner aus demselben .git, jeder auf einem anderen Branch.
• Kontextwechsel wird zu einem cd. Kein git stash und keine Neu-Klone mehr, um einen dringenden Hotfix zu erledigen: du öffnest einen Worktree, arbeitest, schließt ihn, und die ursprüngliche Arbeit bleibt unangetastet.
• Der Build-Zustand überlebt. Jeder Worktree behält seine eigene Indizierung und seinen Compile-Cache: ein Kontextwechsel zwingt die IDE nicht, von vorne zu beginnen.
• Wenige Befehle. git worktree add, git worktree list, git worktree remove, git worktree prune: das ist so ziemlich alles.
• Sie sind der Motor des parallelen Arbeitens von KI-Agenten. Jedem Agenten oder jeder Aufgabe einen isolierten Worktree zuzuweisen, ist das Muster, das mehreren Agenten erlaubt, am selben Repository zu arbeiten, ohne zu kollidieren.
• Ein Schutz zum Merken. Derselbe Branch kann nicht in zwei Worktrees gleichzeitig leben: das ist gewollt, und es ist gut so.

Häufig gestellte Fragen

In welcher Git-Version kamen die Worktrees?

Der Befehl git worktree wurde in Git 2.5 eingeführt, veröffentlicht am 27. Juli 2015. Seitdem ist es ein stabiles Feature und in jeder modernen Git-Installation verfügbar.

Was ist der Unterschied zwischen git worktree und dem erneuten Klonen des Repositorys?

Ein frischer Klon erstellt eine vollständig getrennte Kopie: eine duplizierte Objektdatenbank, doppelter Speicherplatz, neu zu konfigurierende Remotes und keine Verbindung zum Original. Ein Worktree dagegen fügt nur ein Arbeitsverzeichnis hinzu: History, Branches und Objekte bleiben in einem einzigen .git geteilt. Er ist viel leichtgewichtiger, und in einem Worktree erstellte Branches sind für die anderen sofort sichtbar.

Kann ich denselben Branch in zwei Worktrees auschecken?

Nein, und das mit Absicht. Git verhindert, denselben Branch in zwei Worktrees gleichzeitig zu platzieren, um zu vermeiden, dass zwei Ordner seinen Zustand inkonsistent umschreiben. Wenn du es wirklich brauchst, kannst du es mit --force erzwingen, aber fast immer ist die korrekte Lösung, einen Hilfs-Branch zu erstellen.

Warum nutzen KI-Coding-Agenten Worktrees?

Weil sie paralleles Arbeiten ohne Konflikte ermöglichen. Indem jedem Agenten oder jeder Aufgabe ein isolierter Worktree zugewiesen wird, können mehrere Agenten gleichzeitig Dateien ändern, kompilieren und committen, im selben Repository, ohne sich in die Quere zu kommen, und teilen sich dennoch eine einzige History, in die die Ergebnisse zurückfließen.

Wie entferne ich einen Worktree, wenn ich fertig bin?

Nutze git worktree remove <pfad>, um ihn sauber zu löschen. Hast du stattdessen den Ordner von Hand gelöscht, führe git worktree prune aus, um die verwaisten Metadaten aufzuräumen. Mit git worktree list kannst du jederzeit prüfen, welche Worktrees aktiv sind.