Più agenti nello stesso progetto: usare Git worktree
Neaptide · 20 settembre 2026 · 8 min di lettura · Aggiornato: 3 ottobre 2026
Separa i compiti degli agenti con Git worktree: cartelle, rami, ambienti, verifica e integrazione delle modifiche.
In questo articolo
Due agenti che modificano la stessa cartella di lavoro si intralciano. Uno corregge un modulo, l'altro riorganizza un componente e i test girano su un miscuglio di modifiche lasciate a metà. Git worktree separa i file e assegna a ogni attività una cartella e un branch propri.
Un worktree è una copia di lavoro aggiuntiva dello stesso repository Git. La cronologia è comune, ma ogni copia ha il suo branch estratto e i suoi file di lavoro, quindi puoi portare avanti più modifiche insieme. Il manuale Git ne descrive il funzionamento e i comandi.
Quali attività svolgere in parallelo
Parti da due modifiche indipendenti: correggere la gestione degli errori di un modulo e aggiornare un testo di aiuto. Se entrambe toccano uno schema dati o un componente condiviso, concorda prima l'interfaccia e svolgi la parte dipendente in sequenza.
| Attività adatte alla separazione | Ordine da stabilire prima |
|---|---|
| Correzione del modulo e documentazione | Modifica API e interfaccia che ne dipende |
| Test di moduli indipendenti | Due refactoring dello stesso componente |
| Analisi di un bug e modifica di testo separata | Migrazione dei dati e codice per il nuovo schema |
Le cartelle separate impediscono ai file incompleti di mescolarsi. Le contraddizioni funzionali restano: due modifiche possono essere unite senza un solo conflitto Git e, messe insieme, rompere comunque l'applicazione.
Creare due copie di lavoro
L'esempio parte da un repository che ha già almeno un commit. Esegui i comandi dalla sua cartella principale. Non devono esistere ancora branch o cartelle vicine con quei nomi.
git status --short
git worktree add -b ai/form-fix ../project-form HEAD
git worktree add -b ai/docs-update ../project-docs HEAD
git worktree listEntrambe le copie partono dal commit HEAD corrente. Le modifiche non committate nella cartella originale non vengono trasferite. Se servono a entrambe le attività, prepara prima una versione di partenza concordata. Non committare il lavoro incompleto di altri soltanto per seguire l'esempio.
In due terminali distinti, apri le nuove cartelle e avvia l'agente. Per Claude Code:
cd ../project-form
claudeNel secondo terminale apri `../project-docs`. Claude Code sa anche creare la copia da solo: `claude --worktree <nome>` la mette in `.claude/worktrees/`, dentro il repository. I dettagli sono nella guida alle sessioni parallele. Il metodo manuale ha un vantaggio: cartelle e branch restano visibili con qualsiasi client.
Dare istruzioni a ciascun agente
Definisci risultato e ambito del lavoro. Per il primo agente:
Correggi il messaggio di errore dell'invio del modulo nel worktree corrente. Individua il modulo e i relativi test, preservando l'invio riuscito. Non modificare la struttura dell'API o la documentazione. Mostra il diff e i risultati delle verifiche. Non unire i branch.Al secondo affida la documentazione e chiedi espressamente di non toccare il codice del modulo. Sono incarichi di esempio. Usa i percorsi, i comandi e i criteri reali del tuo progetto.
Controlla l'ambiente di ogni copia. Con ogni probabilità dovrai reinstallare le dipendenze e copiare a mano i file di configurazione personali che Git non traccia (`.env`, per esempio). Due server di sviluppo devono usare porte diverse. Se condividono il database di test, separa i dati oppure evita di eseguire nello stesso momento scenari che lo modificano.
Accettare il risultato
Esamina ciascun diff per conto suo. Prima confrontalo con l'incarico, poi guarda i test. Fai il commit delle modifiche verificate, ognuna nel proprio branch.
Unisci i branch uno alla volta nel branch di integrazione scelto. Dopo la seconda unione, verifica di nuovo il percorso utente complessivo. Test riusciti su due branch separati non dimostrano che le modifiche funzionino insieme.
Se emergono conflitti, stabilisci prima quale comportamento deve restare. Non chiedere all'agente di accettare meccanicamente tutte le modifiche di un lato: è il modo più facile per perdere un pezzo dell'altra attività.
Quando rimuovere il worktree
Verifica che le modifiche utili siano salvate e accettate e che non restino file non salvati. Dalla copia principale:
git worktree remove ../project-form
git worktree remove ../project-docsSenza `--force`, Git rifiuta di rimuovere un worktree che contiene ancora modifiche non committate o file non tracciati. Non aggiungere l'opzione soltanto per far sparire l'errore. I branch restano dopo la rimozione delle copie. Che cosa farne si decide a parte.