Git worktrees permiten ejecutar agentes de código en paralelo sin interferencias
El uso de worktrees de Git como entornos aislados permite que múltiples agentes de desarrollo editen simultáneamente sin tocar el mismo estado de trabajo.
El artículo muestra que ejecutar dos agentes de codificación en el mismo repositorio provoca colisiones de archivos, builds incoherentes y falta de trazabilidad de los cambios. La solución propuesta es usar “worktrees”: cada agente obtiene su propio checkout, en un directorio separado, con su propia rama. Así los agentes no comparten el estado mutable y pueden avanzar a velocidad completa. Los worktrees comparten el mismo object store, lo que mantiene el coste de disco bajo. Además, se recomienda que cada worktree se cree a partir de “origin/main”, garantizando un punto de partida limpio y evitando que el estado local del checkout principal se herede y contamine los commits de los agentes. El patrón se aplica principalmente a escritores: agentes que editan archivos. Para lectores, se puede usar un único checkout, pues no hay riesgo de sobrescritura. En proyectos con muchos agentes, el coste de crear cada worktree es mínimo y la consolidación final es trivial porque todas las ramas comparten la misma historia.
¿Por qué funciona?
- Cada agente trabaja en su propio directorio; no hay archivos en común.
- Los cambios se fusionan al final mediante merge o rebase, ya que todas las ramas pertenecen al mismo repositorio.
- El object store se comparte, lo que evita duplicar historia y reduce el uso de disco.
Pasos básicos
# Crear un worktree para un agente
git worktree add ../work-feature-a feat/thing-a
# Segundo agente
git worktree add ../work-feature-b feat/thing-b
Al final, el merge de cada rama al branch principal se realiza sin conflictos de archivos simultáneos.
Cuando no usar worktrees
Si los agentes solo leen archivos o trabajan en partes que nunca se cruzan, un único checkout es suficiente. El overhead de un worktree extra no aporta valor.
Conclusión
El aislamiento por worktree es una práctica madura de Git que escala cuando el número de agentes crece, evitando problemas de concurrencia y simplificando la gestión de estados mutables.
