Git worktrees para agentes de programación con IA: un flujo seguro.
Un Git worktree da a cada tarea sus propios archivos extraídos y su rama actual, pero comparte los objetos y las referencias del repositorio. Sirve para comparar intentos paralelos de agentes sin hacer que editen el mismo directorio de trabajo.
Respuesta breve
Asigna a cada intento un worktree enlazado, una rama y una tarea acotada. Parte en ambos casos del mismo commit base registrado, ejecuta Codex, Claude Code, OpenCode, Cursor u otra herramienta capaz de trabajar en un directorio dentro de su carpeta, y reserva el checkout principal para revisar. Exige resultados confirmados en commits y revisables antes de compararlos.
Elige el resultado que cumpla los criterios, pausa los procesos que escriben, confirma que el checkout de destino esté limpio y haz el merge mediante la revisión y las pruebas habituales. Los worktrees reducen colisiones de archivos, pero no son sandboxes de seguridad: se comparten los objetos, la mayoría de refs y los remotos, y siguen siendo accesibles los recursos autorizados al shell.
1. Crea un worktree limpio por intento
Empieza en el checkout principal. Confirma que esté limpio, actualiza o inspecciona la base prevista, registra ese commit una sola vez y crea las dos ramas desde é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 listAsigna a cada herramienta su carpeta y su rama. No uses la misma rama en dos worktrees ni permitas que la tarea A escriba en la carpeta de la tarea B. La base registrada mantiene la comparación reproducible aunque cambie la rama remota.
Un directorio distinto no limita la autoridad del shell. Reduce credenciales y permisos del host a lo necesario y usa un límite de aprobación independiente para las escrituras Git que requieran control humano.
2. Usa los mismos criterios de aceptación
Entrega a ambos intentos la misma tarea, pruebas, restricciones y base registrada. Pide que excluyan cambios ajenos y confirmen el resultado en su propia rama. Un árbol sin commit es más difícil de comparar y más fácil de perder al limpiar.
Pausa los agentes antes de revisar. El worktree separa archivos extraídos, pero un proceso con permisos amplios aún puede cambiar refs compartidas, contactar remotos o acceder a archivos fuera de su carpeta.
3. Compara ambos intentos desde la base registrada
Revisa el estado de las dos carpetas y compara cada rama con el mismo commit base. Mantén fija esa base en los historiales y 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-bEvalúa comportamiento, pruebas, archivos modificados y alcance. Terminar no basta para hacer merge. Prefiere el intento que cumpla los criterios con el cambio más pequeño y comprensible.
No combines ambos intentos por defecto. Si las buenas ideas están repartidas, aplica un commit verificado o prepara una rama combinada limpia y revisa ese nuevo resultado por separado.
4. Integra el resultado elegido mediante el control normal
Vuelve al checkout principal limpio, selecciona una rama revisada y usa el flujo habitual de merge no fast-forward.
CHOSEN_BRANCH=agent/task-a
git status --short
git diff "$BASE_COMMIT" "$CHOSEN_BRANCH"
git merge --no-ff "$CHOSEN_BRANCH"Mantén pausados los agentes durante el merge. Si aparece un conflicto, detente, inspecciónalo y resuélvelo mediante la revisión normal; el flujo de worktrees no debe convertir un conflicto en una decisión automática.
Ejecuta las pruebas del repositorio después del merge y antes de cualquier push. Los worktrees no sustituyen revisión, CI, ramas protegidas ni aprobación humana, ni impiden que un shell autorizado por separado haga push.
5. Limpia sin forzar
Inspecciona ambas carpetas y conserva cada cambio necesario antes de retirar un checkout enlazado.
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-runRetira un worktree sin forzar solo cuando esté limpio o sus cambios restantes se hayan descartado de forma deliberada. Conserva las ramas hasta cerrar la revisión; eliminar una carpeta y eliminar una rama son decisiones distintas.
Previsualiza el pruning antes de modificar entradas administrativas. La simulación muestra registros obsoletos sin borrarlos. Si Git rechaza la retirada normal, investiga cambios o bloqueos en lugar de saltarte la protección.
Qué separan los worktrees y qué siguen compartiendo
| Separado por worktree | Compartido o todavía accesible |
|---|---|
| Archivos extraídos, cambios de trabajo y artefactos locales | Objetos del repositorio y la mayoría de refs |
| Rama actual y estado HEAD e índice de cada worktree | Remotos, credenciales y configuración compartida |
| Directorio de tarea usado por la herramienta | Todo lo que un shell con permisos amplios alcance fuera de él |
Usa worktrees para paralelizar archivos, aclarar diffs y repetir comparaciones. Usa permisos, ramas protegidas, revisión y aprobaciones para gobernar la autoridad.
La compatibilidad depende de que la herramienta pueda operar en un directorio elegido y respetar el límite de la tarea. Este flujo sirve para herramientas con esa capacidad; no demuestra que todas las herramientas ofrezcan los mismos controles.
Fuentes oficiales de Git
Compara intentos paralelos sin perder el control de revisión.
FluxGit puede mostrar worktrees enlazados y el estado del repositorio, comparar cambios y mantener las propuestas Git de agentes compatibles tras aprobación en escritorio. Un shell separado conserva el acceso concedido por su host.