Uruchamiaj równoległe agenty w izolowanych worktrees

Git worktrees dają równoległym zadaniom agentów osobne mutowalne pliki i branche przy wspólnej bazie obiektów repozytorium. Maksimum w Q13 wymaga więcej niż wielu sesji: automatyzuj tworzenie worktree, przydziel zasoby runtime, dostarczaj zatwierdzoną konfigurację bez swobodnego kopiowania sekretów, uruchamiaj checks w odpowiednim katalogu i integruj dwa do czterech strumieni dopiero po niezależnym review.

Pytanie scorecardu: Jak uruchamiasz równoległe sesje agentów bez kolizji plików?

Maksymalna odpowiedź: Automatyczna orkiestracja zarządza dwoma do czterech izolowanymi strumieniami z jawnym stanem repo, runtime, weryfikacją i cleanup.

Zmapuj izolację na narzędzia

Narzędzie	Opcja zarządzana	Jawny fallback
Claude Code	claude -w WORKTREE_NAME lub claude --worktree WORKTREE_NAME	git worktree add, potem claude w tym katalogu
Cursor	Worktrees w Agents Window, /worktree lub /best-of-n, gdy dostępne	git worktree add, potem otwórz katalog w Cursorze
Codex	Wybierz środowisko worktree dla zadania desktopowego	git worktree add, potem Codex w katalogu; Codex CLI 0.146.0 nie ma --worktree

Kontrolki sprawdzono 4 września 2026 r. w referencji CLI Claude Code, dokumentacji worktrees Cursor i przewodniku worktrees Codex. Przed automatyzacją zweryfikuj zainstalowaną wersję oraz --help lub UI.

Zdefiniuj kontrakt izolacji

Repozytoryjny helper powinien zarządzać:

• unikalnym branchem i katalogiem z jawnej base revision;
• przypisanymi portami app, worker, inspector i test;
• lokalnymi per-worktree ścieżkami database, cache, queue i generated outputs;
• procesem dostarczenia ignorowanej konfiguracji bez logowania sekretów;
• instalacją zależności i dokładnymi komendami weryfikacji;
• ownerem, statusem, wykrywaniem stale worktrees i bezpiecznym cleanup;
• ostrzeżeniami o wspólnych databases, buckets, secrets, deployach i third parties.

Worktree izoluje pliki, nie stan zewnętrzny

Wszystkie worktrees nadal mogą celować w tę samą produkcyjną bazę, cloud account, secret store, port lub third-party service. Domyślnie używaj lokalnych emulatorów i read-only development. Remote migrations, deploye, płatne akcje i shared-secret changes wymagają jawnej ludzkiej autoryzacji.

Utwórz jawny Git worktree

Użyj helpera repozytorium, jeśli istnieje. W innym przypadku, po weryfikacji base brancha, uruchom:

git fetch origin
git worktree add -b codex/fix-auth ../project-codex-fix-auth origin/main
git worktree list

Zastąp codex/fix-auth, ../project-codex-fix-auth i origin/main unikalnym branchem, katalogiem oraz zweryfikowaną base revision. Nie kopiuj generycznie .env. Użyj zatwierdzonego provisioningu repo albo przygotuj minimalną lokalną konfigurację z udokumentowanych placeholders.

Prowadź równoległą pracę bezpiecznie

1. Sprawdź bieżącą własność. Wypisz worktrees, branche, porty i zadania przed utworzeniem nowego strumienia.
2. Wybierz niezależne zadania. Równoleglij osobne pliki lub stabilne interfejsy; sekwencjonuj zmiany tego samego kontraktu.
3. Twórz z jawnego stanu. Zapisz base revision i świadomie zdecyduj o niezacommitowanych zmianach.
4. Przygotuj lokalne zasoby runtime. Przypisz porty i stan, potem udowodnij, że app i tests używają tego katalogu.
5. Ogranicz external access. Używaj lokalnych lub read-only zasobów i zachowaj production gates.
6. Weryfikuj każdy strumień niezależnie. Uruchom dokładne checks i przejrzyj diff przed integracją.
7. Integruj po jednej zmianie. Rebase lub merge względem latest accepted state i ponów affected gates.
8. Sprzątaj bezpiecznie. Usuń wyłącznie potwierdzony worktree; zachowaj branch z unmerged commits.

Prompty do skopiowania

Inspect the repository's worktree helper and current worktree inventory.
Propose an isolated task setup with base revision, branch, directory, ports,
local state, configuration provisioning, verification, and cleanup.
Do not create anything until every shared external resource is identified.

Before reporting this worktree ready, prove the running app and tests use this
checkout, list the base and head revisions, run the required gates, summarize
the diff, and identify any shared cloud state the task could still affect.

Gdy izolacja zawodzi

Kilka kart edytuje jeden checkout. Każde piszące zadanie potrzebuje własnego worktree i brancha.

Dev server po cichu używa portu innego zadania. Przydziel i zweryfikuj porty; przy kilku strumieniach nie ufaj defaultowi.

Sekrety są kopiowane do każdego worktree. Dostarczaj minimalną konfigurację bez logowania values i dokumentuj cleanup.

Niezależne diffy zmieniają ten sam kontrakt. Zatrzymaj równoległość i sekwencjonuj zależną pracę.

Cleanup usuwa unmerged commits. Sprawdź status i reachability brancha; zachowaj stan możliwy do odzyskania.

Zweryfikuj orkiestrację

• Dwa do czterech strumieni ma osobne branche, katalogi, porty i local state.
• Każdy zapisuje base revision i ownera.
• Testy i procesy dowodzą, którego checkoutu używają.
• Shared cloud i produkcja są nazwane i zabezpieczone.
• Każdy diff przechodzi niezależne review przed integracją.
• Cleanup odmawia utraty dirty lub unmerged state bez jawnej decyzji.

Połącz izolację z Build

Używaj worktrees w granicy zaakceptowanego planu z AI-native Build i porównaj zachowanie w mapie narzędzi.

Worktrees Codex Użyj worktrees aplikacji albo jawnych komend Git.

Governance i autonomia Kontroluj wspólny stan zewnętrzny.