Claude Code obecnie jest jednym z głównych narzędzi, z których korzystam na co dzień. Jeśli jeszcze nie miałeś/aś okazji przetestować go w praktyce, to odsyłam do artykułu wprowadzającego. Dowiesz się z niego, jak zacząć z nim pracę. Claude Code potrafi znacznie zwiększyć wydajność pracy, a umiejętne wykorzystanie Claude Code podnosi produktywność jeszcze bardziej.
W tym artykule pokażę Ci jedną z metod, która pozwala na równoległą pracę nad kilkoma zadaniami jednocześnie w ramach jednego repozytorium. Wykorzystamy do tego mechanizm Gitowego worktree.
Czym jest worktree
Standardowo repozytorium Gita wykorzystuje jeden working directory w danej chwili. Chcąc pracować z kilkoma working directories jednocześnie, możemy stworzyć kilka klonów i na każdym z nich stworzyć osobną gałąź. Takie podejście jest jednak nieefektywne. Lokalna historia zmian nie jest dzielona między klonami. Każdy z klonów ma własny katalog .git. Każdy klon zajmuje również dodatkowe miejsce na dysku, co przy ogromnych repozytoriach może mieć znaczenie.
Lepszą alternatywą jest wykorzystanie mechanizmu git worktree. Służy on do tworzenia dodatkowych drzew roboczych, którymi można zarządzać z poziomu jednego repozytorium. Worktrees dzielą zawartość katalogu .git, co pozwala na współdzielenie commitów czy gałęzi. Przydaje się to np. gdy trzeba złączyć efekty pracy z kilku worktrees, korzystając z poleceń merge, rebase czy cherry-pick. Współdzielenie zawartości .git sprawia również, że fetchowanie zmian z repozytorium zdalnego jest wspólne.
Do utworzenia worktree służy polecenie git worktree add <path>. Zwykle tworzy się je poza katalogiem głównego repozytorium. Nazwa folderu, w którym powstaje worktree, domyślnie staje się nazwą nowej gałęzi. Polecenie git worktree add ../foo wywołane w głównym katalogu repozytorium utworzy worktree o nazwie foo wraz z odpowiadającą mu gałęzią foo. Bazą będzie obecnie aktywna gałąź.
Możemy również wskazać branch, który ma być bazą dla worktree, podając go jako kolejny argument, np. git worktree add ../foo feat1. W tym przypadku Git nie utworzy jednak nowej gałęzi a wycheckoutuje feat1 we wskazanej lokalizacji. Warto o tym pamiętać, ponieważ jedna gałąź może być aktywna tylko w jednym worktree. Wywołanie np. git worktree add ../bar feat1 zakończy się błędem fatal: 'feat1' is already used by worktree at '...'. Aby w takim przypadku utworzyć nową gałąź, przy wskazywaniu bazy należy skorzystać z parametru -b np. git worktree add -b foo ../foo feat-1.
Worktree można wylistować poleceniem git worktree list. Oprócz nowo utworzonego worktree pojawi się również main worktree tworzony podczas wywołania git init lub git clone. Niepotrzebne worktree możemy usunąć, korzystając z polecenia git worktree remove.
Wykorzystanie worktree w Claude Code
Do pracy z Claude Code rekomenduję wykorzystanie terminala pozwalającego na uruchomienie kilku kart na jednym widoku lub pracę w kilku kartach. W moim przypadku postawiłem na iTerm2. Praca w ramach jednej instancji terminala pozwoli na szybkie przełączanie się między konwersacjami.
Worktree można zarządzać ręcznie poprzez utworzenie nowej karty, dodanie worktree, przejście do nowego katalogu i uruchomienie Claude Code.
git worktree add ../feat-1
cd ../feat-1
claude
Od wersji 2.1.50 nie jest to już konieczne. W Claude Code pojawiła się możliwość skorzystania z wbudowanej opcji --worktree. Wywołanie claude --worktree spowoduje utworzenie nowego worktree o losowej nazwie w lokalizacji ./.claude/worktrees. Jeśli chcemy utworzyć worktree o konkretnej nazwie, możemy podać ją w poleceniu: claude --worktree <worktree_name>. Po zamknięciu sesji Claude automatycznie usuwa utworzone worktree oraz powiązaną gałąź, jeśli nie ma zmian w working directory ani nowych commitów. Jeśli wprowadzono zmiany, Claude zapyta, czy je zachować. Jeśli odrzucimy zmiany, zarówno worktree, jak i powiązana gałąź zostaną usunęte.
Jeśli zamierzamy korzystać z worktrees, warto zainteresować się opcją konfiguracyjną worktree.symlinkDirectories. Można w niej wskazać katalogi, które mają dostać symlink. Pozwoli to uniknąć np. wielokrotnego instalowania zależności. Z drugiej strony symlinki mogą być problematyczne w przypadkach, gdy np. potrzebujemy użyć innych wersji paczek w ramach różnych worktrees. W takiej sytuacji może dochodzić do konfliktów, błędów lub frustrujących sytuacji, np. gdy myśląc, że korzystamy z jednej wersji, w praktyce korzystamy z innej.
Jak wykorzystać to w praktyce
Podejście, które u mnie się sprawdza, to dawanie Claudowi prostych zadań, w których konieczność mojej interwencji jest ograniczona do minimum. W połączeniu z trybem auto Claude Code może w praktyce działać w tle i realizować proste zadania. W moim przypadku są to np. mechaniczne refaktoryzacje, gdzie trzeba przepisać fragment systemu lub testów z podejścia X na Y czy dopisanie fragmentu prostego CRUD-a. W tym czasie możemy skupić się na poważniejszych tematach. Do Claude deleguję głównie proste zadania lub podzadania, starając się jednocześnie maksymalnie je tłumaczyć. Gdy zadanie jest gotowe, wystarczy sprawdzić, czy zadanie zostało zrobione poprawnie.
Staram się unikać aktywnego skakania między kartami z sesjami Claude. Wraz z liczbą zadań wykonywanych w tym samym czasie powiększa się również nasz kontekst. Praca nad wieloma zadaniami oznacza częsty context switching, co w moim przypadku bardzo negatywnie odbija się na efektywności i komforcie psychicznym.
Podsumowanie
Równoległa praca nad wieloma zadaniami jest możliwa, jednak należy pamiętać, by nie przedobrzyć. Mimo wydelegowania pracy agentowi, wykonanie zadania wciąż wymaga naszej uwagi. Nasz kontekst również ma skończoną pojemność i niestety nie da się go szybko wyczyścić jednym poleceniem. Mimo to wykorzystanie gitowych worktrees to świetny sposób na wyciśnięcie z Claude Code jeszcze więcej. Jeśli nie miałeś/aś okazji popracować z worktrees, to zachęcam do ich wypróbowania.
Jeśli ten artykuł był dla Ciebie pomocny i chcesz pogłębić wiedzę o Gicie, to koniecznie sprawdź Kolejną Książkę o Gicie.
Artykuł jest autopromocją Kolejnej Książki o Gicie.
Źródła i materiały dodatkowe
Zaobserwuj mnie w mediach społecznościowych!
LinkedIn jest głównym medium, poza blogiem, gdzie publikuję swoje przemyślenia. Zachęcam też do zaobserwowania devszczepaniak.pl na Facebooku, gdzie oprócz informacji o nowych artykułach publikuję linki do ciekawych treści.
Udostępnij wpis
Szukasz taniego i dobrego VPS? Skorzystaj z Mikrusa i przy zakupie odbierz dodatkowy miesiąc usługi za darmo!
📖 Koniecznie sprawdź ofertę księgarni Helion oferującej tysiące książek dla programistów w dobrych cenach! Kupując z tego linku, pomagasz w rozwoju bloga.
📈 Szukasz księgowości dla swojej JDG? Skorzystaj z mojego polecenia i odbierz pierwszy miesiąc za 1zł netto!
Chcesz docenić moją pracę? Postaw mi kawę! 
Dalej nie do końca rozumiem czym się różni odpalenie 3 okien terminala i praca Claude z git worktree w każdym z nich gdy robi te drobne kawałki/zadania o których wspomniałeś, od po prostu zwykłego działania Claude w 3 oknach terminala.
Bez worktree każde z okien terminala będzie pracować na tym samym branchu. Jeśli robimy różne zadania, to zmiany z każdego okna będą się mieszać. Chyba że sklonujesz repozytorium kilka razy i opalisz okna z osobnymi klonami, ale o tym, dlaczego nie podoba mi się to podejście, pisałem w artykule.
ok, czyli jeden task/worktree to powiedzmy jedna PR, tak?
dokładnie