Git worktrees: podstawa do uruchamiania wielu agentów AI bez konfliktów

Uruchamiasz dwa agenty na tym samym repo. Jeden edytuje package.json, drugi też. Trzydzieści sekund później twój kod jest w stanie, którego nikt nie scali.

To nie jest bug w twoich agentach. Problem w tym, że wszystkie pracują w tym samym folderze.

Rozwiązanie to narzędzie, które Git ma od lat i prawie nikt go nie używa: git worktree.

Problem: 3 agenty, 1 repo, niemożliwy merge

Normalne repo Gita to jeden folder z jedną gałęzią wczytaną naraz. Pracujesz na main, przełączasz gałąź i cały folder się zmienia.

A teraz wrzuć do tego folderu trzy autonomiczne agenty. Piszą w tym samym momencie. Agent A tworzy plik, agent B robi git checkout, żeby zacząć od zera, i kasuje pracę A w toku. Kończysz z plikami napisanymi w połowie, zepsutym indeksem i konfliktami, których rozplątanie zajmuje więcej czasu, niż gdybyś napisał to sam.

Równoległość oszczędza ci czas tylko wtedy, gdy agenty nie wchodzą sobie w drogę.

Czym jest git worktree

Worktree to drugi folder roboczy podpięty do tego samego repo.

Ta sama historia, to samo zdalne repo, ale każdy worktree ma własną wczytaną gałąź i własne pliki na dysku. Możesz mieć pięć obok siebie, każdy na innej gałęzi, i żaden nie wchodzi drugiemu w paradę.

Jeden .git, kilka przestrzeni roboczych. Tyle.

Jeden worktree na agenta, w praktyce

Tak wygląda konfiguracja. Z poziomu twojego repo:

git worktree add ../project-auth -b feature/auth
git worktree add ../project-billing -b feature/billing
git worktree add ../project-export -b feature/export

Właśnie stworzyłeś trzy foldery, każdy na własnej gałęzi. W każdym uruchamiasz agenta:

cd ../project-auth && claude
cd ../project-billing && codex

Każdy agent ma swój folder, swoją gałąź, swoje pliki. Agent od auth nigdy nie zobaczy, co robi agent od billingu. Żadna kolizja nie jest możliwa.

Gdy funkcja jest gotowa, przeglądasz jej gałąź i scalasz. Potem sprzątasz:

git worktree remove ../project-auth

Folder znika, gałąź zostaje w historii. Czysto.

3 pułapki, o których warto wiedzieć

Pierwsza pułapka: współdzielony plik centralny. Jeśli dwie funkcje obie muszą ruszyć ten sam routes.ts albo ten sam schemat bazy danych, worktrees cię nie uratują, konflikt i tak dostaniesz przy merge'u. Jeden agent dotyka plików, które wszyscy współdzielą, reszta czeka albo kombinuje obejście.

Druga: rozjeżdżające się gałęzie. Gdy twoje agenty pracują, main idzie do przodu. Trzy dni później twoje gałęzie są w tyle i merge robi się bolesny. Rób rebase wcześnie i często albo trzymaj krótkie sesje.

Trzecia: zapomniane sprzątanie. Każdy worktree to prawdziwy folder na twoim dysku. Dziesięć dziennie bez sprzątania i folder nadrzędny robi się nieczytelny. git worktree list pokazuje, co się porozwalało, git worktree prune usuwa te martwe.

Prawdziwe pytanie: kto pilnuje pięciu folderów?

Worktrees rozwiązują kolizje plików. Nie rozwiązują twojego obciążenia umysłowego.

Masz pięć folderów, pięć agentów, pięć terminali. Który czeka na twój przegląd? Który skończył dziesięć minut temu, gdy patrzyłeś gdzie indziej? Który się wywalił?

I tu jeden worktree na agenta trafia na swoją granicę, jeśli zostajesz w terminalu. Rozwiązałeś konflikt techniczny, ale zwielokrotniłeś okna do pilnowania.

AgentsRoom umieszcza każdego agenta na kafelku, z jego statusem i kolorem, niezależnie od tego, w którym worktree działa. Agent, który czeka, robi się czerwony i daje ci znać. Przeczytaj jak uruchamiać od 3 do 8 agentów równolegle, nie tracąc nad nimi panowania, żeby poznać pełną metodę opartą na worktrees.

Co z tego wynieść

Jeden agent, jeden worktree, jedna gałąź. To podstawowa zasada poważnej pracy z wieloma agentami.

Komendy mieszczą się w trzech liniach, korzyść jest natychmiastowa: twoje agenty przestają sobie nawzajem nadpisywać zmiany. Dodaj widok, który mówi ci, który z nich cię potrzebuje, a naprawdę utrzymasz pięć zadań równolegle, nie tracąc głowy.