Git worktree per agenti di coding IA: un flusso sicuro.
Un Git worktree assegna a ogni attività file estratti e branch corrente separati, condividendo però oggetti e riferimenti del repository. Consente di confrontare tentativi paralleli senza far modificare agli agenti la stessa directory.
Risposta breve
Assegna a ogni tentativo un worktree collegato, un branch e un’attività limitata. Avvia entrambi dallo stesso commit base registrato, esegui Codex, Claude Code, OpenCode, Cursor o un altro strumento capace di lavorare in una directory nella cartella assegnata e conserva il checkout principale per la revisione. Richiedi risultati con commit e revisionabili.
Scegli il risultato che soddisfa i criteri, sospendi i processi che scrivono, verifica che il checkout di destinazione sia pulito e fai il merge tramite revisione e test normali. I worktree riducono le collisioni di file, ma non sono sandbox: oggetti, gran parte dei ref e remote sono condivisi, e gli accessi concessi alla shell restano raggiungibili.
1. Crea un worktree pulito per ogni tentativo
Parti dal checkout principale. Verifica che sia pulito, aggiorna o controlla la base prevista, registra quel commit una volta e crea entrambi i branch da lì.
git status --short
git branch --show-current
BASE_COMMIT=$(git rev-parse HEAD)
git worktree add -b agent/task-a ../agent-task-a "$BASE_COMMIT"
git worktree add -b agent/task-b ../agent-task-b "$BASE_COMMIT"
git worktree listAssocia ogni strumento alla propria cartella e al proprio branch. Non usare lo stesso branch in due worktree e non consentire all’attività A di scrivere nella cartella B. La base registrata rende il confronto ripetibile anche se il branch remoto avanza.
Una directory separata non limita l’autorità della shell. Restringi credenziali e permessi dell’host al necessario e usa un confine di approvazione separato per le scritture Git soggette a controllo umano.
2. Usa gli stessi criteri di accettazione
Assegna a entrambi la stessa attività, gli stessi test, vincoli e base. Chiedi agli agenti di evitare modifiche non pertinenti e di creare un commit sul proprio branch. Un albero senza commit è più difficile da confrontare e più facile da perdere durante la pulizia.
Sospendi gli agenti prima della revisione. Il worktree separa i file estratti, ma un processo con ampi permessi può ancora cambiare ref condivisi, contattare remote o raggiungere file fuori dalla cartella.
3. Confronta i tentativi dalla base registrata
Controlla lo stato di entrambe le cartelle e confronta ogni branch con lo stesso commit base. Mantieni fissa la base per log e diff.
git -C ../agent-task-a status --short
git -C ../agent-task-b status --short
git log --oneline "$BASE_COMMIT"..agent/task-a
git log --oneline "$BASE_COMMIT"..agent/task-b
git diff "$BASE_COMMIT" agent/task-a
git diff "$BASE_COMMIT" agent/task-bEsamina comportamento, test, file modificati e ambito. Il completamento non giustifica da solo un merge. Preferisci il tentativo che soddisfa i criteri con la modifica più piccola e comprensibile.
Non fare il merge di entrambi per impostazione predefinita. Se le idee utili sono divise, seleziona un commit verificato o prepara un branch combinato pulito e rivedi separatamente il nuovo risultato.
4. Integra il risultato scelto con il controllo normale
Torna al checkout principale pulito, scegli un branch revisionato e usa il normale percorso di merge non fast-forward.
CHOSEN_BRANCH=agent/task-a
git status --short
git diff "$BASE_COMMIT" "$CHOSEN_BRANCH"
git merge --no-ff "$CHOSEN_BRANCH"Mantieni gli agenti sospesi durante il merge. Fermati in caso di conflitto, esaminalo e risolvilo con la revisione normale; il flusso worktree non deve trasformarlo in una scelta automatica.
Esegui i test del repository dopo il merge e prima di ogni push. I worktree non sostituiscono code review, CI, branch protetti o approvazione umana e non impediscono il push a una shell autorizzata separatamente.
5. Pulisci senza forzare
Esamina entrambe le cartelle e conserva ogni modifica utile prima di rimuovere un checkout collegato.
git -C ../agent-task-a status --short
git -C ../agent-task-b status --short
git worktree remove ../agent-task-a
git worktree remove ../agent-task-b
git worktree list
git worktree prune --dry-runRimuovi un worktree senza forzare solo quando è pulito o il lavoro restante è stato scartato deliberatamente. Conserva i branch fino alla fine della revisione; eliminare la cartella ed eliminare il branch sono decisioni separate.
Visualizza il pruning prima di modificare le voci amministrative. La simulazione mostra le voci obsolete senza rimuoverle. Se Git rifiuta la rimozione normale, indaga modifiche o blocchi invece di aggirare la protezione.
Cosa separano i worktree e cosa condividono ancora
| Separato per worktree | Condiviso o ancora raggiungibile |
|---|---|
| File estratti, modifiche locali e artefatti di build | Oggetti del repository e gran parte dei ref |
| Branch corrente e stato HEAD/indice del worktree | Remote, credenziali e configurazione condivisa |
| Directory di attività usata dallo strumento | Tutto ciò che una shell con ampi permessi può raggiungere |
Usa i worktree per file paralleli, diff più chiari e confronti ripetibili. Usa permessi, branch protetti, revisione e approvazioni per governare l’autorità.
La compatibilità dipende dalla capacità dello strumento di lavorare in una directory scelta e rispettare il limite dell’attività. Il flusso è adatto a questi strumenti; non dimostra che tutti gli strumenti offrano gli stessi controlli.
Fonti Git ufficiali
Confronta tentativi paralleli senza perdere il controllo della revisione.
FluxGit può mostrare worktree collegati e stato del repository, confrontare modifiche e sottoporre le proposte Git degli agenti compatibili all’approvazione desktop. Una shell separata conserva l’accesso concesso dall’host.