Varios agentes en un proyecto: cómo trabajar con Git worktree
Neaptide · 20 de septiembre de 2026 · 8 min de lectura
Separa tareas de agentes con Git worktree: carpetas, ramas, entornos, revisión e integración de cambios.
En este artículo
El trabajo paralelo se complica cuando dos agentes modifican la misma carpeta. Uno corrige un formulario, otro reorganiza un componente y las pruebas evalúan una mezcla de cambios sin terminar. Git worktree separa los archivos: cada tarea tiene su carpeta y su rama.
Un worktree es una copia de trabajo adicional del mismo repositorio Git. El historial se comparte, pero la rama extraída y los archivos de trabajo son independientes. Así pueden desarrollarse varios cambios a la vez. El manual de Git explica el funcionamiento y las órdenes.
Qué tareas pueden hacerse en paralelo
Empiece con dos cambios independientes: corregir el manejo de errores de un formulario y actualizar un texto de ayuda. Si ambos modifican un esquema de datos o un componente compartido, acuerde primero la interfaz y resuelva la dependencia de forma secuencial.
| Buenas tareas independientes | Conviene definir antes el orden |
|---|---|
| Corrección del formulario y documentación | Cambio de API y la interfaz que depende de él |
| Pruebas de módulos independientes | Dos refactorizaciones del mismo componente |
| Investigación de un fallo y cambio de texto ajeno | Migración de datos y código del nuevo esquema |
Las carpetas separadas evitan mezclar archivos incompletos, pero no resuelven contradicciones funcionales. Dos cambios pueden fusionarse sin conflictos de Git y aun así romper la aplicación al combinarse.
Crear dos copias de trabajo
El ejemplo presupone un repositorio existente con al menos un commit. Ejecute las órdenes desde su carpeta principal. Los nombres de las ramas y de las carpetas adyacentes deben estar libres.
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 listAmbas copias parten del commit HEAD actual. Los cambios sin confirmar de la carpeta original no se trasladan. Si ambas tareas los necesitan, prepare primero una versión inicial acordada. No confirme el trabajo inconcluso de otra persona solo para seguir este ejemplo.
Abra las nuevas carpetas en dos terminales distintas y ejecute el agente. Para Claude Code:
cd ../project-form
claudeEn la segunda terminal abra `../project-docs`. Claude Code también permite iniciar sus propios worktrees; consulte la guía de sesiones paralelas. El método manual hace visibles carpetas y ramas independientemente del cliente.
Qué pedir a cada agente
Delimite el resultado y el alcance. Para el primero:
Corrige el mensaje de error de envío del formulario en el worktree actual. Localiza el formulario y sus pruebas, y conserva el envío correcto. No cambies la estructura de la API ni la documentación. Muestra el diff y los resultados de las comprobaciones. No fusiones ramas.Asigne al segundo la documentación, indicando que no modifique el código del formulario. Son ejemplos didácticos: use las rutas, órdenes y criterios reales de su proyecto.
Revise el entorno de cada copia. Las dependencias y los archivos de configuración personales pueden necesitar una preparación independiente. Dos servidores de desarrollo requieren puertos distintos. Si comparten una base de pruebas, separe los datos o evite ejecutar a la vez escenarios que la modifiquen.
Cómo aceptar los resultados
Revise cada diff por separado: primero el cumplimiento del encargo y después las pruebas. Confirme los cambios revisados en sus respectivas ramas.
Fusione una rama cada vez en la rama de integración elegida. Tras la segunda fusión, vuelva a probar el recorrido de usuario completo. Que las pruebas pasen en dos ramas separadas no demuestra que funcionen bien juntas.
Si surgen conflictos, determine qué comportamiento debe mantenerse. No pida aceptar automáticamente todos los cambios de un lado: podría eliminar parte de la otra tarea.
Cuándo eliminar el worktree
Asegúrese de que los cambios necesarios están guardados y aceptados, y de que no quedan archivos sin guardar. Desde la copia principal:
git worktree remove ../project-form
git worktree remove ../project-docsSin una opción de forzado, Git se niega a eliminar un worktree normal con cambios sin confirmar. No añada `--force` solo para evitar el error. Las ramas permanecen después de eliminar las copias; decida por separado qué hacer con ellas. Órdenes worktree.