Git worktree w erze agentów AI

Czym jest git worktree i dlaczego mechanizm ten przez lata był traktowany jako ciekawostka? Dlaczego dziś wraca do gry za sprawą pracy równoległej i narzędzi AI? Czy wart jest całego tego hype'u?

Czym jest git worktree?

Jeśli pracowałeś kiedyś nad projektem, np. proj_foo, na gałęzi feature/X i nagle okazało się, że musisz przełączyć się na inną gałąź, aby wprowadzić pilną poprawkę, miałeś dwie opcje:

• Użyć git stash, chowając bieżące zmiany do „schowka”, następnie wykonać git checkout fix/Y i przełączyć się na inną gałąź, pamiętając, aby później wrócić do poprzedniego zadania.
• Sklonować repozytorium drugi raz do innego katalogu, np. proj_foo_2. W tym przypadku przerywałeś pracę nad tym, co aktualnie miałeś na warsztacie, i „przechodziłeś do drugiego warsztatu (katalogu)”, aby tam robić inną rzecz.

Drzewo robocze, czyli git worktree, to prawie to samo co ponowne sklonowanie repozytorium, tylko bez wielokrotnego klonowania. Zamiast robić:

git clone git@github.com:repo.git ./proj_foo
git clone git@github.com:repo.git ./proj_foo_2

otrzymujesz to samo efektem:

git clone git@github.com:repo.git ./proj_foo
# a potem
cd ./proj_foo
git worktree add ../proj_foo_2 fix/Y

W efekcie powstają dwa katalogi, ale w przypadku drzewa roboczego od razu wskazujesz, którą gałąź chcesz checkoutować.

proj_foo -> main
proj_foo_2 -> fix/Y

Zalety git worktree względem git stash

Wielokrotne klonowanie repozytorium i git worktree rozwiązują bardzo podobny problem - umożliwiają równoległą pracę nad różnymi branchami w osobnych katalogach roboczych. W obu przypadkach można jednocześnie rozwijać kilka feature’ów, przygotowywać hotfixy czy uruchamiać różne wersje aplikacji bez konieczności ciągłego przełączania branchy i używania git stash.

Możliwość równoległej pracy

Największa różnica jest taka, że git stash pozwala tylko chwilowo „odłożyć” zmiany, natomiast git worktree pozwala mieć kilka aktywnych katalogów roboczych jednocześnie. W jednym katalogu możesz mieć niedokończony feature, w drugim hotfix, w trzecim review PR. Nie trzeba odkładać zmian do stasha, przełączać branchy i przede wszystkim pamiętać o tym, aby później odtwarzać stash, by móc kontynuować to, co zmuszeni byliśmy przerwać.

Mniejsze ryzyko konfliktów i utraty stashy

Chowanie na później jest dość „tymczasowym” mechanizmem. Przy większej liczbie schowków łatwo:

• zapomnieć, co zawierają,
• pomylić stash,
• usunąć nie ten stash,
• mieć konflikty przy stash pop.

Drzewo robocze nie ukrywa zmian. Każda praca pozostaje normalnym working tree z pełnym stanem projektu.

Stabilniejsze środowisko robocze

Po przełączeniu się na inne branche zmieniają się nie tylko pliki w katalogu roboczym. Często IDE przebudowuje indeksy, trzeba przebudować kontenery Dockera, przekompilować artefakty itd. Każda z tych operacji kosztuje czas. Przy worktree każdy katalog pozostaje stabilny. Nie zmienia się nagle jego branch ani stan plików.

Możliwość jednoczesnego uruchamiania różnych branchy

To scenariusz praktycznie niemożliwy przy workflow opartym wyłącznie o stash i checkout. Mając dwa lub więcej katalogów roboczych, programista jest w stanie uruchomić tę samą aplikację w dwóch lub więcej wersjach rozwojowych w tym samym czasie.

Tyle że...

Jak już wspomniałem, wszystkie te zalety w porównaniu do git stash dotyczą zarówno drzew roboczych, jak i wielokrotnie sklonowanych instancji repozytorium. Przeglądając znalezione w internecie przypadki użycia git worktree, dochodzę do wniosku, że absolutnie wszystkie są możliwe do realizacji przy użyciu wielokrotnego klonowania i żaden z nich nie uzasadnia potrzeby korzystania z tego mechanizmu.

Skoro tak, to dlaczego do tej pory rzadko klonowałem repozytorium i zwykle wybierałem stash? I co miałoby mnie dziś przekonać do drzew roboczych?

Drzewa robocze nie rozwiązują problemów związanych z konfiguracją środowiska developerskiego i runtime’u.

Z perspektywy środowiska developerskiego oba podejścia mają bardzo podobny koszt. Każdy worktree - podobnie jak każdy osobny clone - jest w praktyce osobnym katalogiem projektu, który zwykle wymaga ponownej konfiguracji lokalnego środowiska. Obejmuje to między innymi:

• utworzenie pliku .env,
• przygotowanie osobnego .venv lub node_modules,
• konfigurację interpretera i ustawień IDE,
• konfigurację lokalnych danych, cache czy build artifacts.

Jeśli projekt korzysta z Dockera, to w obu rozwiązaniach należy dodatkowo zadbać o separację runtime’u, np.:

• unikanie konfliktów portów,
• osobne Docker volumes,
• osobne nazwy projektów Compose,
• osobne zestawy kontenerów

W praktyce oznacza to, że koszt runtime’u - zużycie pamięci RAM, procesora czy przestrzeni dyskowej przez kontenery i środowiska uruchomieniowe - jest bardzo podobny zarówno dla worktree, jak i dla wielu clone’ów repozytorium.

Jeśli konfiguracja Twojego IDE lub szeroko rozumiana konfiguracja środowiska developerskiego jest na tyle bolesna, że powstrzymuje Cię przed utworzeniem kolejnej kopii projektu, to git worktree nie jest antidotum na Twoje bolączki.

Organizacja pracy z Gitem z użyciem git worktree

Główna różnica pomiędzy git worktree a wielokrotnym klonowaniem repozytorium dotyczy nie środowiska uruchomieniowego, lecz samego sposobu przechowywania i zarządzania danymi Git.

W przypadku wielokrotnego klonowania każde repozytorium posiada własny katalog .git, własną historię, osobne referencje branchy, konfigurację, hooki oraz niezależny stan lokalny. Każdy clone jest więc całkowicie osobnym repozytorium Git, nawet jeśli wszystkie pochodzą z tego samego źródła.

git worktree działa inaczej - wszystkie katalogi robocze współdzielą jedno repozytorium Git. Oznacza to wspólną historię commitów, wspólne branche lokalne, wspólne obiekty Git oraz jeden centralny storage danych. Poszczególne worktree to po prostu dodatkowe katalogi robocze podłączone do tego samego repozytorium.

Daje to kilka korzyści:

Mniejsze zużycie miejsca na dane GIT

W każdym worktree są trzymane normalne, pełne pliki projektu. Oszczędność miejsca dotyczy jedynie plików trzymanych w katalogu .git

.git/objects
.git/refs
.git/logs
.git/packed-refs

Jeśli w repozytorium są trzymane duże pliki binarne, historia jest długa i mamy do czynienia z ogromnym monorepo, to korzyść ta może mieć jakiś potencjał. Gdy katalog .git jest mały w porównaniu z runtime’em, wtedy oszczędność na .git jest mało istotna.

Brak konieczności wykonywania fetch w każdym katalogu osobno

To detal, ale dla części osób ma znaczenie - podobnie jak aliasy skracające pojedyncze komendy, np.

# https://x.com/ykdojo/status/2011282303369298240
alias c='claude'

A to po to tylko, aby zaoszczędzić kilka stuknięć na klawiaturze, więc jednokrotne wykonywanie git fetch też ma znaczenie.

Wspólne branche lokalne widoczne we wszystkich worktree

Jeśli pracujesz nad dwoma branchami równocześnie i dochodzisz do momentu, kiedy warto byłoby tymczasowo spiąć je w całość, to chcąc je zmergować, musiałbyś przynajmniej jeden z branchy wypchnąć do zdalnego repo. Niby to nic strasznego, jednak z worktree nie musisz tego robić, ponieważ tworząc branch w jednym drzewie roboczym, jest on automatycznie dostępny we wszystkich drzewach roboczych. To ułatwia merge, rebase i cherry-pick, choć nadal jest to raczej niszowy scenariusz.

Mniejsze ryzyko rozjazdu stanu repozytoriów

Przy wielokrotnym klonowaniu repozytorium każdy clone jest całkowicie niezależnym repozytorium Git. Nawet jeśli wszystkie pochodzą z tego samego origin, to każdy z nich posiada własny stan lokalny: osobne informacje o branchach zdalnych, własny stan po fetch, własne lokalne branche oraz własne metadata Git.

W praktyce oznacza to, że dwa katalogi tego samego projektu mogą po pewnym czasie zacząć się subtelnie różnić. Przykładowo, w jednym clone deweloper wykonał git fetch, więc widzi już nowe branche i aktualny stan origin/main, podczas gdy drugi clone nadal operuje na stanie sprzed kilku dni. Może się też okazać, że branch utworzony lokalnie istnieje tylko w jednym repozytorium, a w drugim nie jest jeszcze dostępny.

Zwykle nie prowadzi to do poważnych problemów, ale potrafi generować drobny chaos organizacyjny. Deweloper zaczyna zastanawiać się:

• czy w tym katalogu zrobiłem już fetch,
• czy ten branch tutaj istnieje,
• czy ten clone jest aktualny,
• czy rebase wykonuję na najnowszym origin/main.

git worktree działa inaczej. Wszystkie katalogi robocze współdzielą jeden wspólny stan repozytorium Git. Branch lokalny utworzony w jednym worktree jest natychmiast widoczny w pozostałych. Wspólne są również informacje o branchach zdalnych oraz stan po fetch. Jeśli w jednym miejscu zostanie pobrany aktualny stan origin, wszystkie worktree od razu widzą te same dane.

W praktyce nie daje to nowych możliwości, ale zmniejsza ilość drobnego „housekeepingu” wokół samego Gita. Nie trzeba pamiętać, który clone jest aktualny i gdzie wykonano ostatni fetch. Wszystkie katalogi robocze pozostają częścią jednego spójnego repozytorium.

Wygodniejsze zarządzanie wieloma katalogami roboczymi

Polecenie git worktree list uruchamiane z poziomu dowolnego drzewa roboczego umożliwia łatwe zorientowanie się w tym, ile tych drzew roboczych jest i jaka gałąź jest aktualnie rozwijana w jakim drzewie.

/projects/app-main      [main]
/projects/app-hotfix    [hotfix/payment]
/projects/app-review    [feature/new-api]

Dostępnych jest także kilka innych poleceń, w tym git worktree remove, służących do usuwania drzewa roboczego. Należy je traktować jako konieczność, gdyż w przypadku worktree nie zaleca się używania rm -rf, ponieważ komenda ta nie usuwa metadanych, które pozostają i zaśmiecają repo.

Wyżej przytoczone zalety worktree nie są spektakularne, niemniej ich suma przekonuje mnie do ich stosowania zamiast ponownego klonowania repozytorium, ale czy to wystarczy, abym w ogóle chciał używać tego na większą skalę?

Organizacja pracy równoległej agentów AI z użyciem git worktree

Przeczytałem gdzieś w otchłani internetu takie zdanie:

"Funkcja Git Worktrees po raz pierwszy zwróciła na siebie uwagę opinii publicznej, gdy firma Anthropic wspomniała o niej w swoich dobrych praktykach dotyczących kodu Claude. Do tej pory była to tylko jedna z tych mało znanych funkcji Gita, o których większość profesjonalistów nigdy nie słyszała."

https://news.ycombinator.com/item?id=44633890

W mojej prywatnej ocenie różnice między worktree a wielokrotnym klonowaniem to tylko nieznaczne usprawnienie, które przy wszystkich kosztach związanych z jego stosowaniem eliminuje zbyt mało wad, aby przed erą AI było warte większej uwagi. Jednak praca ze sztuczną inteligencją zmienia wszystko. To, co wydawało się niewarte zachodu dla dewelopera, który jest w stanie skupić się tylko na jednym zadaniu, a każda zmiana kontekstu wiąże się z koniecznością przekierowania całej uwagi na inne zagadnienie, nabiera wartości w obliczu sztucznej inteligencji mogącej symultanicznie realizować wiele tasków, nie tracąc na efektywności.

Dlaczego git worktree jest warte uwagi w kontekście kodowania wspieranego sztuczną inteligencją?

Znalazłem sporą liczbę artykułów opisujących organizację równoległej pracy wielu agentów AI z wykorzystaniem drzew roboczych. Nie chcę ich tu powielać, więc tylko przytoczę co ciekawsze:

• Supercharge Your AI Coding Workflow: A Complete Guide to Git Worktrees with Claude Code - Myślę, że to niezłe uzupełnienie oficjalnej dokumentacji technicznej Claude Code opisującej mechanizm izolacji równoległych sesji przy użyciu narzędzia git worktree. Autor oferuje gotowe skrypty automatyzujące oraz przedstawia strategie zarządzania wieloma wątkami projektu naraz.
• Git worktree like a boss - Przedstawia alternatywny sposób organizacji katalogów roboczych jako podkatalogów głównego katalogu projektu, przyczyniając się do większego porządku w przestrzeni roboczej dewelopera.
• Scaling Your AI Development Team with Git Worktrees - Tytuł jest nieco „przeskalowany”, ale sam artykuł jest przydatny, bo krok po kroku pokazuje, jak skonfigurować worktree w Visual Studio Code, aby osiągnąć maksymalną produktywność w rozwoju oprogramowania wspieranego przez sztuczną inteligencję.
• Best Git Worktree Tools for AI Coding in 2026 (Compared) - Lista kilku narzędzi oraz krótka analiza ich przydatności w zależności od skali projektu i preferencji programisty.
• Scaling My Development with Git Worktrees and Agentic Workflows - Artykuł jako jeden z nielicznych porusza problem "piekła konfiguracji" i podpowiada kilka technik ułatwiających życie przy tworzeniu nowego katalogu roboczego.

Utworzenie nowego worktree nie jest bezkosztowe

Przy ostatnim z przytoczonych artykułów chciałbym się na chwilę zatrzymać. Choć AI zwykle ma mniejsze wymagania niż człowiek w zakresie konfiguracji środowiska, to, aby móc pracować równolegle, wciąż trzeba zadbać o to, aby każda instancja odpalała projekt na innym porcie, miała możliwość niezależnego uruchamiania testów jednostkowych i linterów do walidowania efektów swojej pracy oraz nie współdzieliła bazy danych czy innych zasobów, jak np. kolejki RabbitMQ, które mogą wzajemnie interferować między instancjami. Oprócz różnicowania konfiguracji dochodzi jeszcze kwestia czasu inicjalizacji. Większość artykułów sprowadza utworzenie nowego katalogu roboczego do wykonania polecenia git worktree, ignorując np. czas potrzebny na utworzenie nowego środowiska wirtualnego .venv i instalację wszystkich zależności albo zbudowanie kompletu obrazów Dockera. Dlatego użycie worktree nie zawsze jest opłacalne, gdyż może się okazać, że przeprocesowanie poprawki w trybie git stash może trwać krócej niż wydzielenie hotfixa do osobnego drzewa roboczego.

Separacja plików to nie to samo co separacja logiki

Dwóch agentów AI może pracować w odseparowanych fizycznie od siebie katalogach, na osobnych branchach i niezależnie modyfikować tę samą funkcję lub kontrakt API. Git często połączy takie zmiany bez konfliktu tekstowego, ale wynik mimo to może łamać testy jednostkowe, prowadzić do konfliktów migracji struktury bazy danych albo nie spełniać założeń biznesowych. Należy pamiętać, że worktree chroni więc przed kolizjami na poziomie systemu plików, ale nie przed kolizjami semantycznymi. Dobra dekompozycja zadań, tak aby każdy agent pracował na możliwie rozłącznym fragmencie systemu, jest kluczem do uniknięcia problemów, ale czasem nawet to nie wystarczy, gdyż po prostu niektóre zadania muszą zwyczajnie poczekać na wykonanie innych.

Człowiek jest wąskim gardłem flow pracy z AI

Chcąc nadzorować pracę takich narzędzi jak Codex czy Claude Code, programista jest zmuszony do ciągłej interakcji z AI. Może oczywiście zaufać sztucznej inteligencji, dać szersze uprawnienia do wykonywania różnych komend systemowych itd., ograniczając w ten sposób konieczność ciągłego nawigowania pomiędzy katalogami i klikania potwierdzeń. Jednak wciąż będzie zmuszony do wprowadzania promptów i weryfikacji rezultatu. Do tego dochodzi koszt zmiany kontekstu, czyli przypomnienie sobie przez dewelopera, nad czym AI akurat pracuje w danym branchu. Czynności wykonywane przez człowieka w wielu przypadkach mogą trwać dłużej niż realizacja nawet całego zadania. Gotowość do delegowania odpowiedzialności oraz opóźnienia wprowadzane przez programistę realnie wpływają na to, jak skutecznie wykorzystasz worktree.

Git worktree powstał jeszcze przed "erą powszechnego wykorzystania AI" i wcale nie był pod to projektowany. Potencjał tego mechanizmu został jednak dostrzeżony i obecnie jego użycie do równoleglenia pracy wielu agentów AI jest uznawane za dobrą praktykę. Choć sztuczna inteligencja zmieniła rachunek zysków i kosztów związanych z użyciem drzew roboczych, opłacalność ich zastosowania w dużym stopniu zależy od charakteru projektu i stopnia zautomatyzowania jego konfiguracji w nowym środowisku deweloperskim.