Qué es y por qué importa
Si abres tres sesiones de Claude Code en la misma carpeta y le das a cada una un trabajo distinto, tarde o temprano se pisan. Una cambia un archivo mientras la otra está trabajando en él, y al final ya no sabes qué cambio viene de quién.
Un worktree resuelve justo esto. Es una copia del proyecto en su propia carpeta, con su propia rama. La historia del proyecto es la misma, porque es una función de git y no un truco de Claude, pero los archivos están separados: lo que Claude cambia en una copia no toca las otras.
Cada sesión de Claude trabaja en su copia: el proyecto principal no lo toca nadie hasta que tú lo decidas. Al final miras qué ha hecho cada una, te quedas con lo que funciona y tiras el resto.
Solo hace falta una cosa: el proyecto tiene que usar git y tener al menos un commit.
1. Una sesión, una copia
Desde el terminal, abre cada sesión ya dentro de su copia. Desde la carpeta del proyecto lanza:
claude --worktree error-login
También vale la versión corta, -w error-login. Claude Code crea la carpeta .claude/worktrees/error-login en una rama nueva, worktree-error-login, y la sesión trabaja ahí dentro.
Dentro de una sesión ya abierta
Si la sesión ya está abierta, o no usas el terminal, escribe lo primero de todo:
Trabaja en un worktree nuevo llamado error-login.
La copia la crea Claude solo y te dice dónde trabaja. En la app de escritorio también puedes elegir la opción worktree cuando abres una sesión nueva.
Repite en otras ventanas con otros nombres: «pagina-precios», «pruebas». Un trabajo por sesión, con un nombre claro: dentro de dos horas tienes que saber de un vistazo qué hay en cada copia.
Una cosa que se hace una sola vez: añade .claude/worktrees/ al archivo .gitignore, así las copias no aparecen como archivos nuevos en el proyecto principal. Se lo puedes pedir a Claude en una línea.
2. Lo que hay que saber antes de empezar
La copia parte de la rama principal online, normalmente main, no de lo que tienes en el ordenador y todavía no has subido. Si tienes commits que aún no has subido con un push, en la copia no están: primero sube, luego abre las copias. Si el proyecto no está online en ningún sitio, la copia parte de donde estás tú.
Luego están los archivos. Una copia solo contiene los archivos que git conoce: no se lleva los archivos excluidos del proyecto, como .env con las claves, ni las librerías instaladas. Si arrancas sin ellos, la app de la copia no se abre o los tests fallan por motivos que no tienen nada que ver con el trabajo.
Para tener .env en cada copia, crea en la carpeta principal del proyecto un archivo .worktreeinclude con una línea dentro:
.env
Claude Code lo lee cada vez que crea una copia y copia dentro los archivos de la lista. Sigue las mismas reglas que el .gitignore y solo copia archivos que git ignora, así que no duplica nada del código. Si tienes otros archivos así, como .env.local, añade una línea para cada uno.
Las librerías, en cambio, hay que instalarlas. En la copia pide:
Instala lo que haga falta en esta copia.
3. Cuando termine: guarda y revisa
Primero guarda. La unión solo ve el trabajo guardado con un commit: lo que solo está en la carpeta de la copia no pasa. En la sesión de la copia escribe:
Haz commit de todo el trabajo de esta copia.
Luego pasa a la sesión principal, la que está abierta en el proyecto de verdad, y escribe:
Enséñame qué cambia la rama worktree-error-login respecto a main, archivo por archivo, y pasa los tests.
Si en la lista aparece un archivo que no tiene nada que ver con el trabajo, como la página de precios en un trabajo sobre el login, pregúntale a Claude por qué lo ha tocado.
4. Une lo que funciona
Siempre desde la sesión principal:
Une la rama worktree-error-login a main. Si hay conflictos, para y explícamelos antes de decidir.
Si la rama principal de tu proyecto no se llama main, por ejemplo master, cambia el nombre en el prompt. Si no estás seguro, pregúntaselo a Claude.
Un conflicto es cuando dos trabajos han cambiado las mismas líneas de forma distinta y alguien tiene que elegir qué versión se queda. Prefiero entender qué elige Claude que descubrirlo después.
De uno en uno: primero uno, tests, luego el siguiente. Si unes tres ramas seguidas y luego algo se rompe, no sabes cuál de las tres ha sido.
5. Tira lo que no funciona
Cuando cierras una sesión que trabaja en una copia, Claude Code mira si dentro hay trabajo: archivos cambiados, archivos nuevos, commits. Si lo hay, te pregunta si quieres conservar la copia o quitarla. Si la copia está limpia y no le has puesto nombre a la sesión, la quita solo.
Si el trabajo no te gusta, quítala: el proyecto principal se queda como estaba. Eso sí, quitar la copia borra la carpeta y su rama, con todo lo que hay dentro. Si ya has unido el trabajo, no pierdes nada, porque ya está en la rama principal.
Si quieres, antes de quitarla pide:
Resúmeme lo que habías probado en esta copia
Así la idea no se pierde. Si en cambio decides conservar la copia, al salir Claude Code te escribe el comando para retomarla más adelante.
Para ver cuántas copias tienes por ahí, pregúntaselo a Claude o lanza git worktree list. Para quitar una a mano está git worktree remove, seguido de la carpeta de la copia.
La regla de oro
Tres trabajos distintos, tres copias. Si dos trabajos tocan los mismos archivos, hazlos uno detrás de otro: las copias evitan los desastres, no los conflictos.
El error del login y la página de precios van perfectos en paralelo, porque están en partes distintas de la app. Rehacer el menú y cambiar los colores de toda la app, no: acaban en los mismos archivos y, cuando vas a unir, te los encuentras todos en conflicto.
Errores comunes
- Dos trabajos que tocan los mismos archivos en dos copias: divídelos por zonas de la app, o hazlos uno detrás de otro.
- Arrancar sin .env y sin librerías: haz preparar la copia antes de dar el trabajo, o pon los archivos en el .worktreeinclude.
- Unir sin commit: lo que solo está en la carpeta no viaja con la rama, así que haz hacer el commit en la copia antes.
- Unirlo todo de golpe: une una rama, pasa los tests y luego sigue con la siguiente.
- Quitar una copia sin mirarla: quitarla también borra la rama, así que antes une o pide un resumen de lo que había dentro.
Lista de comprobación
- El proyecto usa git y tiene al menos un commit
- .claude/worktrees/ está en el .gitignore
- Una sesión por trabajo, cada una en su copia con un nombre claro
- Cada copia tiene .env y librerías antes de empezar
- Commit en la copia, luego revisión desde la sesión principal
- Una rama cada vez, con tests entre medias
- Las copias que ya no sirven están quitadas
Preguntas frecuentes
¿Hace falta usar el terminal sí o sí?
No. Puedes pedirle a Claude que trabaje en un worktree dentro de una sesión ya abierta, con la frase del paso 1. El terminal solo hace falta si quieres abrir la sesión directamente en la copia con --worktree. En la app de escritorio eliges la opción worktree al abrir la sesión.
¿Y si en la copia necesito el trabajo que todavía no he subido?
Tienes dos opciones. La más sencilla es hacer push antes de abrir las copias. La otra es pedirle a Claude que ponga worktree.baseRef en "head" en los ajustes: así las copias parten de donde estás tú en el ordenador, con los commits que todavía no has subido.
¿Las copias se ven entre ellas?
Los archivos no, están separados. La historia de git, en cambio, es compartida: por eso desde la sesión principal puedes ver y unir las ramas de las copias, como en el paso 3. Lo que una copia todavía no ha metido en un commit, eso sí, desde las otras ramas no se ve.