Git worktrees para agentes de programação com IA: um fluxo seguro.
Um Git worktree oferece a cada tarefa seus próprios arquivos em checkout e sua branch atual, enquanto compartilha objetos e refs do repositório. Assim, você compara tentativas paralelas sem fazer agentes editarem o mesmo diretório.
Resposta curta
Dê a cada tentativa um worktree vinculado, uma branch e uma tarefa restrita. Inicie ambas no mesmo commit-base registrado, execute Codex, Claude Code, OpenCode, Cursor ou outra ferramenta capaz de trabalhar em um diretório dentro da pasta atribuída e mantenha o checkout principal para revisão. Exija resultados commitados e revisáveis antes da comparação.
Escolha o resultado que atende aos critérios, pause processos que escrevem, confirme que o checkout de destino está limpo e faça o merge pelo fluxo normal de revisão e testes. Worktrees reduzem colisões de arquivos, mas não são sandboxes de segurança: objetos, a maioria das refs e remotos são compartilhados, e o acesso concedido ao shell continua alcançável.
1. Crie um worktree limpo para cada tentativa
Comece no checkout principal. Confirme que ele está limpo, atualize ou examine a base desejada, registre esse commit uma vez e crie as duas branches a partir dele.
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 listAssocie cada ferramenta à sua pasta e branch. Não abra a mesma branch em dois worktrees nem deixe a tarefa A escrever na pasta da tarefa B. A base registrada mantém a comparação reproduzível mesmo se a branch remota avançar.
Um diretório separado não limita a autoridade do shell. Restrinja credenciais e permissões do host ao necessário e use uma fronteira de aprovação independente para escritas Git que exigem controle humano.
2. Use os mesmos critérios de aceitação
Forneça às duas tentativas a mesma tarefa, testes, restrições e base registrada. Peça que evitem alterações não relacionadas e commitem o resultado na própria branch. Uma árvore sem commit é mais difícil de comparar e mais fácil de perder na limpeza.
Pause os agentes antes da revisão. O worktree separa arquivos em checkout, mas um processo amplamente autorizado ainda pode alterar refs compartilhadas, acessar remotos ou alcançar arquivos fora da pasta da tarefa.
3. Compare as tentativas desde a base registrada
Verifique o status nas duas pastas e compare cada branch com o mesmo commit-base. Mantenha essa base fixa nos históricos e diffs.
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-bRevise comportamento, testes, arquivos alterados e escopo. Concluir a tarefa não basta para fazer merge. Prefira a tentativa que cumpre os critérios com a menor mudança compreensível.
Não una as duas tentativas por padrão. Se boas ideias estiverem divididas, selecione um commit verificado ou prepare uma branch combinada limpa e revise o novo resultado separadamente.
4. Integre o resultado escolhido pelo fluxo normal
Volte ao checkout principal limpo, selecione uma branch revisada e use o caminho habitual de merge não fast-forward.
CHOSEN_BRANCH=agent/task-a
git status --short
git diff "$BASE_COMMIT" "$CHOSEN_BRANCH"
git merge --no-ff "$CHOSEN_BRANCH"Mantenha os agentes pausados durante o merge. Pare diante de qualquer conflito, examine-o e resolva-o pelo processo normal; o uso de worktrees não deve transformar conflito em decisão automática.
Rode os testes do repositório após o merge e antes de qualquer push. Worktrees não substituem revisão, CI, proteção de branches ou aprovação humana, nem impedem push por um shell autorizado separadamente.
5. Limpe sem forçar
Examine as duas pastas e preserve tudo o que deseja manter antes de remover um checkout vinculado.
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-runRemova um worktree sem força somente quando ele estiver limpo ou quando o trabalho restante tiver sido descartado de propósito. Mantenha as branches até concluir a revisão; remover a pasta e apagar a branch são decisões diferentes.
Visualize o pruning antes de alterar registros administrativos. A simulação mostra entradas obsoletas sem removê-las. Se o Git recusar a remoção normal, investigue alterações ou bloqueios em vez de ignorar a proteção.
O que os worktrees separam e o que ainda compartilham
| Separado por worktree | Compartilhado ou ainda alcançável |
|---|---|
| Arquivos em checkout, mudanças locais e artefatos de build | Objetos do repositório e a maioria das refs |
| Branch atual e estado HEAD/índice de cada worktree | Remotos, credenciais e configuração compartilhada |
| Diretório de tarefa usado pela ferramenta | Tudo que um shell amplo alcança fora dele |
Use worktrees para paralelismo de arquivos, diffs claros e comparação repetível. Use permissões, branches protegidas, revisão e aprovações para governar autoridade.
A compatibilidade depende de a ferramenta trabalhar em um diretório escolhido e respeitar o limite da tarefa. O fluxo serve para ferramentas com essa capacidade; não prova que todas as ferramentas oferecem os mesmos controles.
Fontes oficiais do Git
Compare tentativas paralelas sem perder o controle da revisão.
O FluxGit pode mostrar worktrees vinculados e o estado do repositório, comparar mudanças e manter propostas Git de agentes compatíveis sob aprovação no desktop. Um shell separado conserva o acesso dado pelo host.