Cos'è e perché conta
Se apri tre sessioni di Claude Code nella stessa cartella e dai a ognuna un lavoro diverso, prima o poi si pestano i piedi. Una cambia un file mentre l'altra ci sta lavorando, e alla fine non capisci più quale modifica viene da chi.
Un worktree risolve proprio questo. È una copia del progetto in una cartella sua, con un ramo suo. La storia del progetto è la stessa, perché è una funzione di git e non un trucco di Claude, ma i file sono separati: quello che Claude cambia in una copia non tocca le altre.
Ogni sessione di Claude lavora nella sua copia: il progetto principale non lo tocca nessuno finché non decidi tu. Alla fine guardi cosa ha fatto ciascuna, tieni quello che va bene e butti il resto.
Serve solo una cosa: il progetto deve usare git e avere almeno un commit.
1. Una sessione, una copia
Da terminale apri ogni sessione già nella sua copia. Dalla cartella del progetto lancia:
claude --worktree bug-login
Va bene anche la versione corta, -w bug-login. Claude Code crea la cartella .claude/worktrees/bug-login su un ramo nuovo, worktree-bug-login, e la sessione lavora lì dentro.
Dentro una sessione già aperta
Se la sessione è già aperta, o non usi il terminale, scrivi come prima cosa:
Lavora in un worktree nuovo chiamato bug-login.
La copia la crea Claude da solo e ti dice dove lavora. Nell'app desktop puoi anche scegliere l'opzione worktree quando apri una sessione nuova.
Ripeti in altre finestre con altri nomi: «pagina-prezzi», «test». Un lavoro per sessione, con un nome chiaro: tra due ore devi capire al volo cosa c'è dentro ogni copia.
Una cosa da fare una volta sola: aggiungi .claude/worktrees/ al file .gitignore, così le copie non compaiono come file nuovi nel progetto principale. Puoi chiederlo a Claude in una riga.
2. Da sapere prima di partire
La copia parte dal ramo principale online, di solito main, non da quello che hai sul computer e non hai ancora caricato. Se hai dei commit che non hai ancora mandato online con un push, nella copia non ci sono: prima carica, poi apri le copie. Se il progetto non è online da nessuna parte, la copia parte da dove sei tu.
Poi ci sono i file. Una copia contiene solo i file che git conosce: non si porta dietro i file esclusi dal progetto, come .env con le chiavi, né le librerie installate. Se parti senza, l'app nella copia non si avvia o i test falliscono per motivi che non c'entrano niente col lavoro.
Per avere .env in ogni copia, crea nella cartella principale del progetto un file .worktreeinclude con dentro una riga:
.env
Claude Code lo legge ogni volta che crea una copia e ci copia i file elencati. Segue le stesse regole del .gitignore e copia solo i file che git ignora, quindi non duplica niente del codice. Se hai altri file così, tipo .env.local, aggiungi una riga per ciascuno.
Le librerie invece vanno installate. Nella copia chiedi:
Installa quello che serve in questa copia.
3. Quando ha finito: salva e controlla
Prima salva. L'unione vede solo il lavoro salvato con un commit: quello che resta solo nella cartella della copia non passa. Nella sessione della copia scrivi:
Fai commit di tutto il lavoro in questa copia.
Poi passa alla sessione principale, quella aperta nel progetto vero, e scrivi:
Fammi vedere cosa cambia il ramo worktree-bug-login rispetto a main, file per file, e fai girare i test.
Se nell'elenco trovi un file che non c'entra col lavoro, tipo la pagina dei prezzi in un lavoro sul login, chiedi a Claude perché l'ha toccato.
4. Unisci quello che va bene
Sempre dalla sessione principale:
Unisci il ramo worktree-bug-login in main. Se ci sono conflitti fermati e spiegameli prima di decidere.
Se il ramo principale del tuo progetto non si chiama main, tipo master, cambia il nome nel prompt. Se non sei sicuro, chiedilo a Claude.
Un conflitto è quando due lavori hanno cambiato le stesse righe in modo diverso e qualcuno deve scegliere quale versione tenere. Preferisco capire cosa sceglie Claude, invece di scoprirlo dopo.
Uno alla volta: prima uno, test, poi il successivo. Se unisci tre rami di fila e poi qualcosa si rompe, non sai quale dei tre è stato.
5. Butta quello che non va
Quando chiudi una sessione che lavora in una copia, Claude Code guarda se dentro c'è del lavoro: file cambiati, file nuovi, commit. Se c'è, ti chiede se tenere la copia o toglierla. Se la copia è pulita e non hai dato un nome alla sessione, la toglie da solo.
Se il lavoro non ti piace, toglila: il progetto principale resta com'era. Togliere la copia però cancella la cartella e il suo ramo, con tutto quello che c'è dentro. Se il lavoro l'hai già unito non perdi niente, perché è già nel ramo principale.
Se vuoi, prima di toglierla chiedi:
Riassumimi cosa avevi provato in questa copia
Così l'idea non si perde. Se invece decidi di tenere la copia, all'uscita Claude Code ti scrive il comando per riprenderla più avanti.
Per vedere quante copie hai in giro, chiedilo a Claude oppure lancia git worktree list. Per toglierne una a mano c'è git worktree remove, seguito dalla cartella della copia.
La regola d'oro
Tre lavori diversi, tre copie. Se due lavori toccano gli stessi file, falli uno dopo l'altro: le copie evitano i disastri, non i conflitti.
Il bug del login e la pagina dei prezzi vanno benissimo in parallelo, perché stanno in punti diversi dell'app. Rifare il menu e cambiare i colori di tutta l'app no: finiscono negli stessi file e al momento di unire te li ritrovi tutti in conflitto.
Gli errori più comuni
- Due lavori che toccano gli stessi file in due copie: dividili per zona dell'app, oppure falli uno dopo l'altro.
- Partire senza .env e senza librerie: fai preparare la copia prima di dare il lavoro, o metti i file nel .worktreeinclude.
- Unire senza commit: quello che resta solo nella cartella non passa col ramo, quindi fai fare il commit nella copia prima.
- Unire tutto in una volta: unisci un ramo, fai girare i test, poi passa al successivo.
- Togliere una copia senza guardarla: togliere cancella anche il ramo, quindi prima unisci o fatti riassumere quello che c'era dentro.
Checklist
- Il progetto usa git e ha almeno un commit
- .claude/worktrees/ è nel .gitignore
- Una sessione per lavoro, ognuna nella sua copia con un nome chiaro
- Ogni copia ha .env e librerie prima di partire
- Commit nella copia, poi controllo dalla sessione principale
- Un ramo alla volta, con i test in mezzo
- Le copie che non servono più sono tolte
Domande frequenti
Serve per forza il terminale?
No. Puoi chiedere a Claude di lavorare in un worktree dentro una sessione già aperta, con la frase del passo 1. Il terminale serve solo se vuoi aprire la sessione già nella copia con --worktree. Nell'app desktop scegli l'opzione worktree quando apri la sessione.
E se nella copia mi serve il lavoro che non ho ancora caricato?
Hai due strade. La più semplice è fare il push prima di aprire le copie. L'altra è chiedere a Claude di impostare worktree.baseRef su "head" nelle impostazioni: così le copie partono da dove sei tu sul computer, con i commit che non hai ancora caricato.
Le copie si vedono tra loro?
I file no, sono separati. La storia di git invece è condivisa: per questo dalla sessione principale puoi vedere e unire i rami delle copie, come al passo 3. Quello che una copia non ha ancora messo in un commit, però, dagli altri rami non si vede.