Varios agentes en un proyecto: cómo trabajar con Git worktree
Neaptide · 20 de septiembre de 2026 · 8 min de lectura · Actualizado: 3 de octubre de 2026
Separa tareas de agentes con Git worktree: carpetas, ramas, entornos, revisión e integración de cambios.
En este artículo
Dos agentes que modifican la misma carpeta de trabajo se estorban. Uno corrige un formulario, otro reorganiza un componente y las pruebas se ejecutan sobre una mezcla de cambios a medio hacer. Git worktree separa los archivos y da a cada tarea su carpeta y su rama.
Un worktree es una copia de trabajo adicional del mismo repositorio Git. El historial es común, pero cada copia tiene su rama extraída y sus archivos de trabajo, de modo que puedes llevar varios cambios a la vez. El manual de Git explica cómo funciona y qué comandos hay.
Qué tareas pueden hacerse en paralelo
Empieza 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, acuerda primero la interfaz y haz la parte dependiente por orden.
| 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 en otro archivo | Migración de datos y código del nuevo esquema |
Las carpetas separadas impiden que se mezclen archivos a medio hacer. Las contradicciones funcionales siguen ahí: dos cambios pueden fusionarse sin un solo conflicto de Git y, aun así, romper la aplicación al juntarse.
Crear dos copias de trabajo
El ejemplo parte de un repositorio que ya tiene al menos un commit. Ejecuta los comandos desde su carpeta principal. No debe existir todavía ninguna rama ni carpeta vecina con esos nombres.
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, prepara primero una versión inicial acordada. No confirmes el trabajo inconcluso de otra persona solo para seguir este ejemplo.
Abre las nuevas carpetas en dos terminales distintas y ejecuta el agente. Para Claude Code:
cd ../project-form
claudeEn la segunda terminal abre `../project-docs`. Claude Code también sabe crear la copia por su cuenta: `claude --worktree <nombre>` la deja en `.claude/worktrees/`, dentro del repositorio. Los detalles están en la guía de sesiones paralelas. El método manual tiene una ventaja: carpetas y ramas quedan a la vista con cualquier cliente.
Qué pedir a cada agente
Delimita 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.Al segundo encárgale la documentación y dile expresamente que no toque el código del formulario. Los dos encargos son ejemplos. Usa las rutas, los comandos y los criterios reales de tu proyecto.
Revisa el entorno de cada copia. Lo normal es que haya que instalar otra vez las dependencias y copiar a mano los archivos de configuración personales que Git no sigue (`.env`, por ejemplo). Dos servidores de desarrollo necesitan puertos distintos. Si comparten una base de pruebas, separa los datos o no ejecutes a la vez escenarios que la modifiquen.
Cómo aceptar los resultados
Revisa cada diff por separado. Primero compáralo con el encargo y después mira las pruebas. Confirma los cambios revisados, cada uno en su rama.
Fusiona una rama cada vez en la rama de integración elegida. Tras la segunda fusión, vuelve a probar el recorrido de usuario completo. Que las pruebas pasen en dos ramas separadas no demuestra que funcionen bien juntas.
Si surgen conflictos, decide primero qué comportamiento debe mantenerse. No le pidas al agente que acepte sin más todos los cambios de un lado, porque así es fácil perder parte de la otra tarea.
Cuándo eliminar el worktree
Asegúrate 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 `--force`, Git se niega a eliminar un worktree que todavía tiene cambios sin confirmar o archivos sin seguimiento. No añadas la opción solo para que desaparezca el error. Las ramas siguen ahí después de eliminar las copias. Qué hacer con ellas se decide aparte.