Git worktree: două sarcini în două directoare de lucru

Lucrați împreună cu Claude Code la un ghid al localelor: implementați căutarea în listă și sunteți abia la jumătate. Deodată observați că versiunea salvată a paginii are o etichetă greșită sub titlu. Corectarea durează două minute, dar ați vrea s-o verificați separat, nu amestecată cu căutarea neterminată.

Vom vedea cum îi puteți oferi celei de-a doua sarcini propriul director de lucru în același repository, cum deschideți acolo o sesiune Claude Code separată și cum salvați rezultatul fără să încurcați lucrurile. Al doilea director nu accelerează lucrul de la sine. Are un singur scop: să nu se amestece cele două sarcini în același set de fișiere.

Când un singur director de lucru nu ajunge

Proiectul de exercițiu locale-guide este o pagină web cu o listă de locale. În directorul lui lucrați acum la sarcina A: căutarea, pe branch-ul feature/search, cu o modificare încă neterminată:

git status --short
 M app.js

Modificarea aceasta nu trebuie pierdută, dar e prea devreme s-o considerați un rezultat gata. Între timp apare sarcina B, fără legătură cu căutarea: să corectați eticheta din index.html, în versiunea salvată pe main.

Primul impuls ar putea fi să deschideți un al doilea terminal și să porniți încă un claude în același director. Conversațiile ar fi diferite, dar fișierele ar fi aceleași. Dacă ambele sesiuni modifică aceleași zone, schimbările se pot amesteca. În exemplul nostru simplu, eticheta și căutarea sunt încă în fișiere diferite, dar ambele sesiuni văd proiectul comun, neterminat. Iar schimbarea branch-ului cere să vă ocupați de modificările curente.

Soluția este să-i dați sarcinii B propriul spațiu de lucru. Git oferă pentru asta un director de lucru separat al aceluiași repository, numit worktree. Claude Code are flag-ul --worktree, care pregătește un astfel de director și pornește imediat o sesiune acolo. Să vedem mai întâi mecanismul, apoi flag-ul.

Un repository, mai multe directoare de lucru, fiecare cu propriul branch. Numele din imagine sunt arbitrare; în exemplul nostru sunt două directoare de lucru și trei branch-uri: main, feature/search și fix/label.

O precizare de la bun început: nu e o metodă obligatorie pentru orice sarcină. Dacă arborele de lucru e curat și modificarea e scurtă, al doilea director doar vă adaugă bătăi de cap. E perfect în regulă și să alternați sarcinile în același director.

Branch, director de lucru și sesiune

Sunt trei lucruri ușor de confundat, fiindcă de obicei le folosiți în același timp:

Așa se explică și ce se întâmplă în al doilea terminal: sesiunea nouă separă conversația, dar nu și fișierele. Pentru a separa fișierele, aveți nevoie de un al doilea director de lucru.

Istoricul și branch-urile sunt comune: ambele directoare sunt legate de același repository. În mod implicit, setările Git sunt comune, deși Git permite și setări separate pentru worktree. În schimb, fiecare director are propriile fișiere de lucru și propriile modificări pregătite pentru commit. Căutarea necomisă din primul director nu va apărea singură în al doilea.

De regulă, nu puteți deschide același branch simultan în două directoare. Git va refuza și vă va indica directorul care îl folosește deja:

fatal: 'fix/label' is already used by worktree at '/projects/locale-guide-label'

Alegeți starea de bază

În exemplul nostru, repository-ul este deja creat, are cel puțin un commit, branch-ul local main și branch-ul feature/search. Deocamdată, ambele indică același commit, iar căutarea există doar ca modificare necomisă. Să verificăm starea inițială cu trei comenzi, din directorul principal:

git status --short        # ce modificări nu sunt salvate acum
git branch --show-current # pe ce branch se află directorul principal
git log -1 --oneline main # ultimul commit de pe main

 M app.js
feature/search
d5ec405 add locale guide page

Pentru a corecta eticheta separat, alegem main: sarcina B are nevoie de versiunea salvată a paginii, nu de starea curentă a căutării. Rețineți că este branch-ul local main de pe computerul dumneavoastră. Nu trebuie să coincidă cu branch-ul omonim de pe server, iar comanda nu descarcă nimic din rețea.

Dacă a doua sarcină are nevoie de rezultatul primei, stabiliți mai întâi de ce commit salvat are nevoie, apoi creați directorul pornind de la acel commit. Comanda obișnuită git worktree add nu transferă automat modificările necomise. Copierea separată a fișierelor sau folosirea unor instrumente suplimentare pentru configurarea mediului sunt acțiuni distincte.

Creați un al doilea director de lucru

Din directorul locale-guide:

git worktree add -b fix/label ../locale-guide-label main

Comanda se citește de la stânga la dreapta: creează branch-ul nou fix/label, pune directorul de lucru alături, la calea ../locale-guide-label, și ia main ca punct de plecare. Ultimul argument face alegerea bazei explicită. Fără el, Git ar folosi commit-ul curent HEAD al branch-ului feature/search, dar nu și modificările necomise. În exemplul nostru, branch-urile sunt încă la același commit, deci fișierele ar fi identice; după commit-uri în branch-ul de căutare, alegerea bazei va schimba rezultatul. Git răspunde aproximativ astfel:

Preparing worktree (new branch 'fix/label')
HEAD is now at d5ec405 add locale guide page

Apoi verificăm rezultatul. Flag-ul -C îi spune lui Git să execute comanda în directorul indicat, fără să schimbe directorul curent:

git worktree list
git -C ../locale-guide-label branch --show-current
git -C ../locale-guide-label status --short

Un rezultat de exemplu, cu căi fictive. La dumneavoastră căile vor fi altele:

/projects/locale-guide        d5ec405 [feature/search]
/projects/locale-guide-label  d5ec405 [fix/label]

fix/label

Lista afișează ambele directoare și branch-ul fiecăruia. Directorul principal a rămas pe feature/search, cu căutarea neterminată, iar cel nou este pe fix/label. Comanda status nu a afișat nimic pentru al doilea director: e curat, exact ce ne doream.

Dacă nu puteți folosi calea sau numele branch-ului, Git va refuza și va explica de ce, de exemplu already exists sau is already used by worktree. Verificați lista worktree-urilor, branch-urile și conținutul directorului indicat. Poate fi vorba de o rulare anterioară sau de o altă sarcină. Nu adăugați la întâmplare --force: verificați mai întâi ce există deja și dacă vă mai trebuie.

Deschideți a doua sarcină în Claude Code

Deschideți locale-guide-label într-o fereastră IDE separată sau navigați acolo dintr-un terminal nou și porniți claude. Sesiunea nouă nu știe nimic despre sarcina A, ceea ce e în regulă: are nevoie doar de propriul context:

Director așteptat: locale-guide-label, branch: fix/label.
Verifică mai întâi directorul și branch-ul reale. Dacă sunt altele, oprește-te.
Citește index.html.
Schimbă eticheta de sub titlu în "Lista de locale: cod, limbă și țară".
Nu mai modifica nimic în fișier și arată-mi schimbarea.

După modificare, verificați git status și git diff în ambele terminale: în al doilea director s-a schimbat doar eticheta din index.html, iar în primul a rămas modificarea inițială din app.js. Comanda status, singură, afișează numele fișierelor, dar nu confirmă că și conținutul lor a rămas intact. Pentru o comparație exactă, întrerupeți temporar lucrul la căutare. Verificați directorul principal din terminalul lui; nu-i cereți agentului din sesiunea izolată să navigheze acolo. Deschideți pagina din al doilea director, altfel veți vedea eticheta veche.

Există și o cale mai scurtă. Comanda claude --worktree label-fix creează singură directorul de lucru și pornește o sesiune acolo. Conform documentației actuale, directorul apare în repository, în .claude/worktrees/label-fix/, branch-ul se numește worktree-label-fix, iar baza este branch-ul implicit al repository-ului la distanță (de obicei main), nu commit-ul curent. Dacă repository-ul la distanță nu este configurat, se folosește commit-ul local curent. Așadar, nu e același lucru cu main indicat explicit în comanda de mai sus, deși într-un proiect simplu rezultatul coincide adesea. Puteți schimba valoarea implicită din setări; verificați documentația versiunii dumneavoastră pentru detalii.

Flag-ul e util când baza vi se potrivește și vreți să pregătiți rapid un spațiu separat pentru sarcină. Nu e nevoie să-l rulați pentru un director deja creat: veți obține încă unul. Adăugați și .claude/worktrees/ în .gitignore, altfel conținutul noilor directoare va apărea în directorul principal ca fișiere neurmărite.

Ce rămâne comun

Un director separat izolează mai puține lucruri decât ați putea crede la prima vedere:

A treia coloană e cea mai importantă și tocmai ea e ușor de uitat. Worktree ține de fișierele Git, nu izolează calculatorul. Două servere locale nu pot folosi același port, iar cererile din ambele directoare ajung la aceeași bază de date externă, dacă asta indică setările. Nici verificările pe care le face Claude Code într-un director separat nu îl transformă într-un sandbox pentru întregul sistem.

Al doilea director primește fișierele din commit-ul ales. Dacă dependențele și setările locale nu sunt păstrate în Git, de obicei trebuie să pregătiți separat mediul; instrumentele suplimentare pot automatiza acest proces. Nu copiați orbește fișierul .env: aceleași date de conectare pot trimite ambele rulări către același serviciu. Ghidul nostru static nu are nevoie nici de server, nici de secrete; pagina se deschide direct ca fișier.

Salvați și transferați rezultatul

În directorul B, verificați eticheta în browser, consultați git diff și includeți în commit doar fișierul necesar:

git add index.html
git diff --cached
git commit -m "fix: correct locale list label"

Înainte de commit, asigurați-vă că este pregătită doar modificarea dorită. Dacă git diff --cached afișează și alte schimbări, clarificați mai întâi ce e cu ele.

Commit-ul a ajuns în repository-ul comun și este vizibil deja din directorul principal. Dar nu a intrat automat nici în main, nici în feature/search: a rămas pe branch-ul lui, până când decideți să-l integrați.

Transferați rezultatul doar după ce sarcina A este terminată sau măcar salvată, iar directorul principal este curat. Nu schimbați branch-ul pe main în mijlocul unei căutări neterminate; ocupați-vă mai întâi de ea. După ce directorul principal e curat:

git checkout main
git merge fix/label

Fast-forward
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Acest rezultat apare dacă main nu s-a schimbat după crearea lui fix/label. Dacă Git semnalează un conflict, opriți-vă și rezolvați-l conform regulilor de merge; e un subiect separat, explicat în articolul "Ramuri și îmbinări în Git". După integrare, deschideți din nou pagina: eticheta ar trebui să fie nouă, iar lista de locale să fi rămas neschimbată. Branch-ul feature/search nu s-a actualizat: înainte să continuați căutarea, decideți separat dacă trebuie să aduceți corectarea din main și acolo.

Eliminați directorul de care nu mai aveți nevoie

Închideți mai întâi sesiunea din al doilea director și tot ce ați pornit acolo. Apoi verificați dacă a mai rămas ceva util:

git -C ../locale-guide-label status --short --ignored

Fișierele noi și modificate apar direct; flag-ul --ignored le afișează pe cele ignorate, unde se găsesc adesea setările locale și notițele. După ce vă asigurați că rezultatul e salvat pe branch-ul potrivit, eliminați directorul, rulând comanda din directorul principal:

git worktree remove ../locale-guide-label
git worktree list

Dacă există fișiere urmărite modificate sau fișiere noi care nu sunt ignorate, de regulă Git va refuza să elimine directorul:

fatal: '../locale-guide-label' contains modified or untracked files, use --force to delete it

Nu executați ca prim pas comanda sugerată în mesaj. Verificați fișierele și salvați ce vă trebuie. După eliminare, datele necomise s-ar putea să nu mai poată fi recuperate cu Git. Refuzul lui Git nu este o protecție completă: fișierele ignorate pot fi șterse și fără --force, de aceea le-am verificat separat.

Mai e un detaliu ușor de trecut cu vederea. Comanda Git elimină directorul de lucru, nu și branch-ul: după aceea, fix/label va apărea în continuare în lista git branch. E util, fiindcă rezultatul nu dispare. Când branch-ul nu vă mai trebuie și ați integrat tot ce era necesar din el, ștergeți-l separat.

Nu ștergeți directorul din File Explorer, ocolind Git: repository-ul va continua să-l considere existent, iar în lista worktree va rămâne o înregistrare pentru ceva ce nu mai este acolo.

Cum să lucrați la a doua sarcină în Claude Code

Întregul proces încape în șase pași:

1. formulați a doua sarcină separat de prima și decideți de la ce stare salvată pornește;
2. creați un director de lucru cu baza indicată explicit sau porniți claude --worktree, dacă valoarea implicită vi se potrivește;
3. verificați calea și branch-ul din noul director înainte să modificați ceva;
4. oferiți sesiunii contextul doar pentru această sarcină, fără istoricul celeilalte;
5. verificați modificarea chiar în directorul în care ați făcut-o și includeți rezultatul într-un commit;
6. decideți dacă integrați schimbările și abia apoi eliminați directorul.

Directorul separat nu verifică codul și nu validează munca în locul dumneavoastră. Îi permite fiecărei sarcini să aibă propriile fișiere de lucru. În exemplul nostru, avantajul e clar: eticheta a fost corectată și verificată separat, iar căutarea neterminată a rămas în primul director.

Verificați ce ați înțeles

În al doilea director nu apare căutarea necomisă. S-a întâmplat ceva greșit?
Nu, așa trebuie. Directorul a fost creat pornind de la commit-ul de pe main, nu de la fișierele curente ale sarcinii A. Modificările necomise rămân în directorul lor.

Sunt deschise două sesiuni în același director. Sunt sarcinile separate?
Conversațiile sunt separate, dar fișierele sunt comune. Modificările se pot amesteca dacă sarcinile ating aceleași zone.

Commit-ul din branch-ul B a fost creat, dar eticheta nu apare pe main.
Așa trebuie: commit-ul se află pe branch-ul lui. Nu modifică alte branch-uri; pentru asta trebuie să integrați schimbările.

Al doilea server local nu pornește pe același port.
Directoarele separate nu izolează porturile. Porniți serverul pe alt port.

Git a refuzat să elimine directorul de lucru.
Citiți motivul refuzului: pe lângă fișierele nesalvate, directorul poate fi blocat sau poate fi directorul principal de lucru. Salvați ce vă trebuie și verificați starea. Nu adăugați la întâmplare --force.

Dacă vreți să exersați, folosiți un repository separat de exercițiu, cu câteva commit-uri: creați două directoare, schimbați textul doar în al doilea, verificați-le pe amândouă și eliminați-l pe cel de care nu mai aveți nevoie. Nu aveți nevoie de servicii sau conturi.