Por Anónimo (no verificado) , 29 Abril 2026

El problema que resuelven los worktrees

Estás a mitad de feature cuando llega una solicitud urgente de hotfix. Hacer stash o cambiar de contexto es arriesgado y lento. Los worktrees te dejan hacer checkout de ramas adicionales en directorios separados, todos compartiendo una base de datos de objetos subyacente. Cada worktree tiene su propio HEAD, índice y árbol de trabajo.

Añadir un worktree

git worktree add ../hotfix main
cd ../hotfix
git checkout -b hotfix/urgent
# arregla el bug, push, vuelve
cd -
git worktree remove ../hotfix

Listar y podar

git worktree list
git worktree list --porcelain
git worktree prune
git worktree remove ../old-feature
git worktree lock ../release
git worktree unlock ../release

Worktrees desacoplados

git worktree add --detach ../v1.0 v1.0.0

Reglas de compartición de ramas

La misma rama no puede estar en checkout en dos worktrees simultáneamente, por diseño.

Casos de uso

  • Build largo de CI en un worktree mientras sigues codificando.
  • Comparación lado a lado de dos ramas en tu editor.
  • Bisect en un worktree mientras tu checkout principal queda fijo.
  • Ejecutar múltiples versiones de lenguaje o builds de contenedor en paralelo.

Configuración

git config --worktree user.email [email protected]

Habilita con git config extensions.worktreeConfig true.

Errores comunes

Eliminar un directorio de worktree con rm -rf en lugar de git worktree remove deja metadatos viejos; git worktree prune limpia.