Git worktrees: varias ramas en paralelo sin stash ni segundo clon

Git permite desde hace tiempo asociar varias copias de trabajo a un mismo repositorio, cada una en su propia rama y en su propio directorio. El comando git worktree evita apilar entradas de stash para saltar de una tarea a otra y volver a clonar un proyecto entero solo para abrir una corrección rápida. El mecanismo es estable, está presente en cualquier versión reciente de Git y resulta útil mucho más allá de los repositorios enormes.

#El problema que resuelven los worktrees

El escenario es habitual: una funcionalidad está en curso, el árbol de trabajo está sucio y una corrección urgente cae en la rama de producción. Los reflejos de siempre tienen su coste. git stash aparta el trabajo pero obliga a lidiar con una pila invisible, y no separa ni las dependencias instaladas ni los artefactos de build. El clon completo duplica todo el historial y consume disco para un repositorio que ya está en local.

Un worktree ofrece una tercera vía: un directorio adicional, asociado al repositorio existente, que lleva otra rama. El trabajo en curso queda intacto en su directorio, la corrección se abre al lado y ambos conviven sin pisarse.

Una rama por directorio, un solo historial: el cambio de contexto ya no cuesta un stash.

#Crear, listar y situar un worktree

Un worktree se crea con un comando, a partir de una rama existente o creándola de paso. El primer argumento es la ruta del nuevo directorio; el segundo, la rama que se coloca en él.

# Añadir un worktree para una rama existente
git worktree add ../paiement-hotfix hotfix/paiement

# Crear la rama junto con el worktree
git worktree add -b correctif-tva ../correctif-tva main

# Listar los worktrees asociados al repositorio
git worktree list

El directorio principal sigue siendo el worktree por defecto; los demás se le suman. git worktree list muestra su ruta, el commit actual y la rama asociada, lo que da una visión inmediata de los frentes abiertos.

#Qué se comparte y qué no

Todos los worktrees de un repositorio comparten un único directorio .git: historial, objetos, ramas y remotos son comunes. Un commit hecho en un worktree se ve al instante desde los demás, sin push ni fetch. Ese uso compartido es justo lo que abarata la operación en disco frente a un clon.

En cambio, cada worktree tiene sus propios archivos de trabajo, su índice y su HEAD. Lo que vive fuera del seguimiento de Git no acompaña: las dependencias instaladas (por ejemplo node_modules), los archivos de entorno ignorados y los artefactos de build son propios de cada directorio. Es una ventaja, pues un build lanzado en un worktree no pisa el de otro, pero implica reinstalar las dependencias en cada directorio nuevo.

#Casos de uso concretos

La corrección urgente es el ejemplo típico, pero la herramienta sirve para otras rutinas diarias:

• Revisión de código: sacar la rama de un pull request en un worktree dedicado permite ejecutarla de verdad, probarla y compararla, sin perturbar el trabajo en curso.
• Builds largos: una compilación o una suite de pruebas costosa puede correr en un worktree mientras el desarrollo continúa en otro.
• Bisect: aislar una regresión con git bisect en un worktree aparte mantiene limpio el árbol de trabajo principal.
• Comparar versiones: mantener dos ramas abiertas en paralelo para cotejar dos implementaciones de una misma página o API.

Para un autónomo que compagina varios encargos, la ventaja es clara: un repositorio de cliente puede alojar en paralelo la rama de la funcionalidad facturada y la corrección de producción pedida con urgencia, sin mezclas y sin volver a clonar.

#Detalles útiles para el día a día

Algunos puntos ayudan a exprimir el mecanismo. En un worktree secundario, el .git no es un directorio sino un simple archivo que apunta al repositorio principal: ese enlace es lo que da acceso al historial compartido. Como la configuración y los hooks viven en el repositorio común, se aplican a todos los worktrees, lo que homogeneiza los entornos sin copia manual.

Tres comandos completan el arsenal. git worktree add --detach crea un directorio en estado detached, útil para una prueba desechable sin crear una rama. git worktree move traslada un worktree existente a otra ruta. git worktree lock lo protege cuando reside en un soporte extraíble o un montaje de red, para que prune no lo elimine durante una ausencia. Del lado del editor la lógica es inmediata: cada worktree se abre como una carpeta de proyecto independiente, con su propia ventana y su propia terminal.

Queda la cuestión de la ubicación. Colocar los worktrees en un directorio hermano del proyecto, o en una carpeta dedicada que reúna las copias de un mismo repositorio, mantiene el árbol legible y evita anidar un worktree dentro de otro. Como los remotos se comparten, un git fetch lanzado desde cualquier worktree actualiza las referencias para todos, lo que ahorra idas y vueltas a la red. Ese ahorro, invisible en un proyecto pequeño, se vuelve tangible en un repositorio pesado donde cada clon adicional se pagaría en minutos y en gigabytes.

#Limpiar y esquivar las trampas

Una vez fusionada la rama, el worktree se retira con limpieza. Borrar el directorio a mano deja referencias huérfanas que git worktree prune limpia.

# Retirar un worktree cuando la rama ya está fusionada
git worktree remove ../paiement-hotfix

# Limpiar las referencias a worktrees borrados a mano
git worktree prune

#Lo que hay que recordar

Los worktrees superan al dúo stash más clon en cuanto hay que mantener dos contextos abiertos a la vez. Comparten el historial para seguir siendo ligeros, aíslan los archivos de trabajo para evitar colisiones y se manejan con tres comandos: add, list, remove. El hábito que hay que adquirir es limpiar los directorios terminados, para no dejar copias de trabajo olvidadas.

#Para profundizar

Git — Documentación oficial de git-worktree

#Lea también en Mail Studio

• Herramientas de línea de comandos para el desarrollo web
• Copias de seguridad automatizadas de un servidor web: el método que aguanta