Git Worktrees: jak Copilot izoluje pracę agenta

Czego się nauczysz

• Czym różni się git worktree od brancha — i dlaczego Copilot CLI go używa
• Jak sprawdzić co agent stworzył po sesji i jak to posprzątać
• Kiedy worktree isolation ma sens, a kiedy workspace isolation jest wygodniejszy

Skąd to pytanie

W poprzedniej lekcji Copilot CLI zaproponował dwa tryby: worktree isolation i workspace isolation. Wybrałeś worktree, bo brzmiało bezpieczniej.

Po zakończeniu sesji agenta znalazłeś się z katalogiem, który VS Code pokazuje jako osobne repozytorium w Source Control — i nie do końca wiedziałeś, co to jest, jak to usunąć ani dlaczego to nie jest po prostu “osobny branch”.

Ta lekcja odpowiada na te pytania.

Branch to wskaźnik. Worktree to katalog

To fundamentalna różnica, którą warto mieć w głowie przed wszystkim innym.

Branch — to wskaźnik na commit w historii gita. Nie ma fizycznej reprezentacji na dysku jako osobny folder. Kiedy przełączasz się między branchami, jeden katalog zmienia zawartość. Master “znika”, feature “pojawia się” — ale to wciąż ten sam katalog.

Worktree — to fizyczny katalog na dysku, w którym wypchany jest konkretny branch. Możesz mieć wiele takich katalogów jednocześnie, każdy na innym branchu, wszystkie podpięte do tego samego repozytorium Git. W praktyce linked worktree ma u siebie plik .git, który wskazuje na wspólne metadane repozytorium.

flowchart LR
subgraph BRANCH["BRANCH — jeden katalog"]
  direction TB
  bd["projekt/"]
  bg[".git/"]
  bc["git checkout feature\n→ katalog zmienia zawartość\n(tylko jeden branch aktywny)"]
  bd --- bg
  bd --> bc
end

subgraph WORKTREE["WORKTREE — wiele katalogów, wspólne repo Git"]
  direction TB
  wg["repo/.git/ — common dir"]
  w1["projekt/ (main worktree) ← main"]
  w2[".worktrees/feature/ (.git → common dir) ← feature"]
  w3[".worktrees/agent/ (.git → common dir) ← copilot/task"]
  wg --- w1
  wg --- w2
  wg --- w3
end

BRANCH -.->|"git worktree add"| WORKTREE

Git worktrees istnieją od wersji 2.5 (2015). Przez lata programiści obchodzili ten problem przez git clone do osobnego folderu, co duplikowało całą historię. Worktree robi to samo, ale bez duplikacji — jeden .git, wiele okien na historię.

Jak Copilot CLI tworzy worktree automatycznie

Kiedy wybierasz worktree isolation w Copilot CLI, dzieje się coś konkretnego pod spodem. Nie jest to żadna magia — to standardowy git, uruchamiany automatycznie przez CLI.

sequenceDiagram
actor D as Deweloper
participant C as Copilot CLI
participant G as git
participant W as .worktrees/copilot-xyz

D->>C: Uruchom sesję (worktree isolation)
C->>G: git worktree add -b copilot/task .worktrees/copilot-xyz
G-->>W: Tworzy linked worktree + checkout brancha
Note over D: projekt/ — nienaruszony przez cały czas
Note over W: CLI commituje zmiany na końcu każdej tury
C->>W: Agent pracuje tutaj
W-->>D: Sesja zakończona
D->>D: Przejrzyj zmiany agenta
alt Zmiany OK
  D->>G: git merge lub PR
  D->>G: git worktree remove .worktrees/copilot-xyz
  D->>G: opcjonalnie git branch -d copilot/task
else Odrzucam
  D->>G: git worktree remove .worktrees/copilot-xyz
  D->>G: git branch -D copilot/task
end

To dlatego worktree isolation jest naprawdę izolacją, a nie tylko obietnicą izolacji. Twój główny katalog jest fizycznie osobnym miejscem na dysku.

Co widzisz w VS Code

VS Code widzi każdy worktree jako osobne “repozytorium” w panelu Source Control. Stąd ta niepokojąca notyfikacja — nagle masz “nowe repo” w bocznym panelu.

To nie jest błąd. To feature gita. VS Code wykrywa, że masz katalog z plikami śledzonymi przez ten sam .git co główne repozytorium i traktuje go jak osobny workspace.

Po usunięciu worktree notyfikacja znika.

Kiedy wybrać worktree, a kiedy workspace

To samo pytanie, które lekcja o Copilot CLI zostawiała bez pełnego kontekstu. Teraz możesz podjąć tę decyzję świadomie.

Jedno ograniczenie, o którym warto pamiętać: w trybie worktree poziom permission jest automatycznie ustawiony na Bypass Approvals i nie możesz go zmienić. Agent ma pełną swobodę w swoim katalogu. Możesz to zaakceptować świadomie, bo jego zmiany nie dotykają Twojego głównego katalogu — ale nie zignoruj tego faktu.

Lifecycle: inspekcja i cleanup

Po zakończeniu sesji agenta masz trzy komendy, które warto znać.

Sprawdź co istnieje:

git worktree list

Pokaże wszystkie aktywne worktree — ścieżkę, commit i branch. Jeśli widzisz niespodziewane wpisy, to właśnie tutaj je znajdziesz.

Usuń konkretny worktree:

git worktree remove .worktrees/copilot-abc123

Usuwa katalog i wyrejestrowuje worktree z gita.

Jeśli worktree jest brudny, git odmówi i trzeba najpierw posprzątać zmiany albo świadomie użyć --force.

Posprzątaj martwe referencje:

git worktree prune

Usuwa wpisy, gdzie katalog już nie istnieje fizycznie — przydatne, gdy ktoś usunął folder ręcznie i git o tym nie wie.

Po cleanup usuń też branch agenta. Jeśli branch został zmergowany, użyj bezpiecznego -d. Jeśli świadomie porzucasz niezmergowane commity agenta, dopiero wtedy użyj -D.

git branch -d copilot/task-abc123

albo:

git branch -D copilot/task-abc123

Co z pracą agenta po sesji

Worktree izoluje pracę, ale nie rozwiązuje za Ciebie decyzji o tym, co z nią zrobić. Masz trzy opcje:

• Merge — przenieś zmiany do głównego brancha normalnym git merge albo przez PR
• Cherry-pick — wyciągnij tylko wybrane commity, jeśli agent zrobił za dużo albo za mało
• Discard — usuń worktree bez merge, jeśli efekt nie jest potrzebny

To dobra wiadomość: możesz przejrzeć całą pracę agenta przed podjęciem jakiejkolwiek decyzji. To właśnie jest promień ryzyka, który worktree isolation redukuje.

Ćwiczenie praktyczne

Wykonaj ręcznie to, co Copilot CLI robi automatycznie:

1. Stwórz worktree w swoim repozytorium:

git worktree add -b test/worktree-exercise .worktrees/test-isolation

2. Sprawdź co VS Code pokazuje w panelu Source Control.
3. Otwórz `.worktrees/test-isolation/` i wprowadź dowolną zmianę w pliku.
4. Sprawdź, że katalog główny projektu tej zmiany nie widzi.
5. Posprzątaj:
```bash
git worktree remove .worktrees/test-isolation
git branch -d test/worktree-exercise

Cel: zobaczyć fizycznie, że dwa katalogi koegzystują jednocześnie — i poczuć co Copilot CLI robi pod spodem przy worktree isolation.

Kluczowe wnioski

• Branch to wskaźnik na commit. Worktree to fizyczny katalog na dysku. To nie jest to samo.
• Copilot CLI tworzy worktree automatycznie — standardowy git, nie żadna magia.
• VS Code pokazuje każdy worktree jako “nowe repozytorium” w Source Control — to normalne zachowanie, nie błąd.
• Cleanup po sesji agenta to Twoja odpowiedzialność: git worktree remove + opcjonalnie git branch -d.
• Worktree isolation ma sens dla dużych i ryzykownych zmian. Dla szybkiej iteracji workspace isolation jest wygodniejszy.

Co dalej

Zamykasz moduł o ekosystemie agentów. Następny blok idzie poziom wyżej: context engineering, TDD z Copilotem i debugowanie z AI — techniki pracy, które odróżniają używanie Copilota od naprawdę skutecznego używania Copilota.