Git Worktrees für KI-Coding-Agenten: ein sicherer Ablauf.
Ein Git Worktree gibt jeder Aufgabe eigene ausgecheckte Dateien und einen aktuellen Branch, teilt aber Objekte und Referenzen des Repositorys. So lassen sich parallele Agentenversuche vergleichen, ohne dass sie dasselbe Arbeitsverzeichnis bearbeiten.
Die kurze Antwort
Gib jedem Versuch einen verknüpften Worktree, einen Branch und eine eng begrenzte Aufgabe. Starte beide vom selben festgehaltenen Basis-Commit, führe Codex, Claude Code, OpenCode, Cursor oder ein anderes verzeichnisfähiges Werkzeug in seinem Ordner aus und nutze den primären Checkout für das Review. Verlange committete, prüfbare Ergebnisse vor dem Vergleich.
Wähle das Ergebnis, das die Kriterien erfüllt, pausiere schreibende Prozesse, bestätige einen sauberen Ziel-Checkout und merge über den normalen Review- und Testweg. Worktrees verringern Dateikollisionen, sind aber keine Sicherheits-Sandboxes: Objekte, die meisten Refs und Remotes werden geteilt; vom Shell-Host erlaubte Zugriffe bleiben erreichbar.
1. Erstelle je Versuch einen sauberen Worktree
Beginne im primären Checkout. Prüfe, dass er sauber ist, aktualisiere oder kontrolliere die vorgesehene Basis, halte diesen Commit einmal fest und erstelle beide Branches daraus.
git status --short
git branch --show-current
BASE_COMMIT=$(git rev-parse HEAD)
git worktree add -b agent/task-a ../agent-task-a "$BASE_COMMIT"
git worktree add -b agent/task-b ../agent-task-b "$BASE_COMMIT"
git worktree listOrdne jedem Werkzeug seinen Ordner und Branch zu. Checke denselben Branch nicht in zwei Worktrees aus und lasse Aufgabe A nicht in Ordner B schreiben. Die festgehaltene Basis hält den Vergleich reproduzierbar, auch wenn sich der Remote-Branch bewegt.
Ein separates Verzeichnis begrenzt keine Shell-Berechtigung. Beschränke Zugangsdaten und Host-Rechte auf die Aufgabe und nutze eine eigene Freigabegrenze für Git-Schreibvorgänge, die menschliche Kontrolle brauchen.
2. Nutze dieselben Abnahmekriterien
Gib beiden Versuchen dieselbe Aufgabenbeschreibung, Tests, Grenzen und Basis. Jeder Agent soll sachfremde Änderungen vermeiden und sein Ergebnis auf dem eigenen Branch committen. Ein nicht committeter Arbeitsbaum ist schwerer zu vergleichen und beim Cleanup leichter zu verlieren.
Pausiere die Agenten vor dem Review. Der Worktree trennt ausgecheckte Dateien, doch ein weitreichend berechtigter Prozess kann gemeinsame Refs ändern, Remotes erreichen oder auf Dateien außerhalb des Aufgabenordners zugreifen.
3. Vergleiche beide Versuche mit derselben Basis
Prüfe den Status in beiden Aufgabenordnern und vergleiche jeden Branch mit demselben Basis-Commit. Verwende diese feste Basis für Logs und Diffs.
git -C ../agent-task-a status --short
git -C ../agent-task-b status --short
git log --oneline "$BASE_COMMIT"..agent/task-a
git log --oneline "$BASE_COMMIT"..agent/task-b
git diff "$BASE_COMMIT" agent/task-a
git diff "$BASE_COMMIT" agent/task-bPrüfe Verhalten, Tests, geänderte Dateien und Umfang. Ein abgeschlossener Lauf ist noch kein Merge-Grund. Bevorzuge den Versuch, der die Kriterien mit der kleinsten verständlichen Änderung erfüllt.
Merge nicht standardmäßig beide Versuche. Sind gute Ideen verteilt, übernimm einen geprüften Commit oder erstelle einen sauberen kombinierten Branch und prüfe dieses neue Ergebnis separat.
4. Merge das gewählte Ergebnis über den normalen Prozess
Kehre zum sauberen primären Checkout zurück, wähle einen geprüften Branch und nutze den üblichen Non-Fast-Forward-Mergeweg.
CHOSEN_BRANCH=agent/task-a
git status --short
git diff "$BASE_COMMIT" "$CHOSEN_BRANCH"
git merge --no-ff "$CHOSEN_BRANCH"Lass die Agenten während des Merges pausiert. Stoppe bei Konflikten, prüfe sie und löse sie im normalen Reviewprozess; der Worktree-Ablauf darf daraus keine automatische Entscheidung machen.
Führe nach dem Merge und vor jedem Push die Repository-Tests aus. Worktrees ersetzen weder Review, CI, Branch-Schutz noch menschliche Freigabe und verhindern keinen Push durch eine separat berechtigte Shell.
5. Räume ohne Force auf
Prüfe beide Worktree-Ordner und sichere jede gewünschte Änderung, bevor du einen verknüpften Checkout entfernst.
git -C ../agent-task-a status --short
git -C ../agent-task-b status --short
git worktree remove ../agent-task-a
git worktree remove ../agent-task-b
git worktree list
git worktree prune --dry-runEntferne einen Worktree ohne Force nur, wenn er sauber ist oder verbliebene Arbeit bewusst verworfen wurde. Behalte die Aufgaben-Branches bis zum Abschluss des Reviews; Ordner und Branch zu löschen sind getrennte Entscheidungen.
Zeige Pruning vor Änderungen an administrativen Einträgen nur als Vorschau. Verweigert Git das normale Entfernen, untersuche Änderungen oder Sperren, statt die Sicherung zu umgehen.
Was Worktrees trennen und was sie weiter teilen
| Pro Worktree getrennt | Geteilt oder weiter erreichbar |
|---|---|
| Ausgecheckte Dateien, Arbeitsänderungen und Build-Artefakte | Repository-Objekte und die meisten Refs |
| Aktueller Branch sowie Worktree-HEAD und Index | Remotes, Zugangsdaten und gemeinsame Konfiguration |
| Aufgabenordner des Werkzeugs | Alles außerhalb, das eine weit berechtigte Shell erreicht |
Nutze Worktrees für parallele Dateien, klare Diffs und wiederholbare Vergleiche. Regle Befugnisse mit Berechtigungen, geschützten Branches, Review und Freigaben.
Kompatibilität hängt davon ab, ob ein Werkzeug in einem gewählten Verzeichnis arbeiten und die Aufgabengrenze respektieren kann. Der Ablauf passt zu solchen Werkzeugen; er beweist keine gleichen Kontrollen bei allen Werkzeugen.
Offizielle Git-Quellen
Vergleiche parallele Versuche, ohne die Review-Kontrolle aufzugeben.
FluxGit kann verknüpfte Worktrees und Repository-Status zeigen, Änderungen vergleichen und Git-Vorschläge unterstützter Agenten an Desktop-Freigaben binden. Eine separate Shell behält die vom Host gewährten Rechte.