¿Cuándo aparece la necesidad? (el momento exacto)
El momento llega cuando tu proyecto crece y una sola IA, haciendo una cosa a la vez, se te queda corta. Quieres avanzar más rápido: que mientras una sesión construye una feature, otra arregle un bug y una tercera pruebe una idea nueva — todo al tiempo. También cuando dudas entre dos caminos ("¿lo hago así o asá?") y quieres ver los dos antes de decidir. O cuando quieres probar algo arriesgado sin tocar lo que ya funciona. En todos esos casos, ir de a una cosa a la vez sobre tu única versión es lento y frágil.
¿Qué es un "worktree"? (en cristiano)
En la guía de GitHub viste las ramas: copias paralelas de tu proyecto. Un worktree lleva eso un paso más allá: te deja tener varias de esas ramas abiertas y vivas al mismo tiempo, cada una en su propia carpeta, sin que una toque a la otra. Mientras una IA trabaja en la "idea A", otra puede estar en la "idea B", y tu versión principal sigue intacta. No es de a una en una — es todas a la vez.
El superpoder · una rama por idea, con Claude en VS Code
Claude Code tiene una extensión oficial para VS Code (también funciona en Cursor y compatibles). Desde ahí abres varias sesiones de IA en paralelo, cada una en su propio worktree, y ves los cambios que propone con un diff visual (lado a lado) que apruebas o rechazas. Lo mejor: crear un worktree aislado es un solo comando.
claude --worktree mi-idea-arriesgada
Eso crea una copia aislada de tu proyecto (en .claude/worktrees/mi-idea-arriesgada/) sobre una rama nueva, sin tocar tu versión principal. Trabajas la idea ahí; si funciona, la unes; si no, la borras y no pasó nada. Puedes abrir otra sesión con claude --worktree otra-idea y tener las dos compitiendo a la vez.
3 escenarios donde esto te salva
Así trabajamos nosotros · varias sesiones a la vez (el gran acelerador)
Este es el beneficio más grande, y es exactamente cómo construimos: en vez de una sola IA avanzando en fila india, tenemos varias sesiones trabajando en paralelo, cada una en su propio worktree. La sesión 1 construye una parte del producto, la sesión 2 arma otra cosa distinta, una sesión 3 podría estar probando una idea nueva — las tres avanzando AL MISMO TIEMPO, sin pisarse. Es como tener tres empleados en vez de uno, cada uno en su escritorio, sin estorbarse.
El review visual · apruebas o rechazas, tú mandas
Dentro de VS Code, cuando la IA quiere cambiar un archivo, te muestra una comparación lado a lado: lo que había vs. lo que propone. Tú decides: aceptar, rechazar, o decirle qué cambiar. Nada se modifica a tus espaldas. Es como tener al empleado mostrándote cada cambio antes de aplicarlo, en vez de que toque todo y tú te enteres después.
La rutina de oro · avanzar en paralelo sin caos
- Una sesión = una rama/worktree: cada frente de trabajo en su copia aislada. Nunca varios sobre la versión principal.
- Push a TU rama, nunca a la principal: cada sesión guarda en lo suyo; la principal solo recibe vía merge.
- Audita con C-A-R antes de unir: ninguna rama entra a la principal sin pasar su auditoría/debug primero.
- Revisa el diff en VS Code antes de aceptar — tú mandas, no la IA.
- Fusiona solo lo que quedó impecable: la pieza terminada y auditada se une; las ideas que no cuajaron se borran sin culpa.
Prompt listo · monta tu flujo de trabajo en paralelo
Cópialo y pégaselo a tu agente de código para que te guíe a trabajar en varios frentes a la vez, sin que tengas que aprender comandos:
Quiero avanzar más rápido en mi proyecto trabajando en VARIAS sesiones en paralelo, cada una en su propia versión aislada (worktree), sin que se pisen ni rompan mi versión principal. Guíame en lenguaje simple, asumiendo que no sé de git. 1. Explícame en una frase qué es un worktree (una copia viva y aislada de mi proyecto). 2. Voy a trabajar en estos frentes a la vez: [lista tus tareas, ej: "1) rediseñar el inicio, 2) arreglar el login, 3) probar una idea nueva"]. Crea un worktree dedicado para cada uno, ramificando desde mi versión estable. 3. Dime cómo abrir VS Code en cada worktree para ver el diff y aprobar/rechazar los cambios visualmente. 4. REGLA IMPORTANTE: cada sesión debe hacer push a SU PROPIA rama, NUNCA a la principal (main). La principal solo recibe cosas vía merge. 5. Cuando termine una tarea en su worktree, antes de unirla: aplícale el protocolo C-A-R (audita, depura, déjala impecable). Recién entonces haz el merge de esa rama a la principal, y resuelve cualquier conflicto en lenguaje natural. 6. Si una idea no cuajó, ayúdame a descartar su worktree sin que mi proyecto principal se entere. Regla de oro: avanzo en paralelo, pero a la rama principal solo entra lo auditado, vía merge — nunca a medias.