Estás a mitad de una funcionalidad y llega el mensaje: “Necesitamos corregir esto cuanto antes”.
Tienes archivos modificados, ideas a medias y una rama que todavía no está lista. Necesitas atender la urgencia sin desacomodar lo que estabas haciendo.
Aquí es donde Git worktrees resulta útil: puedes abrir otra rama del mismo repositorio en una carpeta diferente y trabajar en ambas sin cambiar continuamente de rama en un único directorio.
Esta guía forma parte de mi serie sobre Git y GitKraken para la comunidad de habla hispana.
En el primer artículo practicamos ramas, staging y commits. Ahora vamos a usar esos conceptos para resolver una interrupción cotidiana.
¿Qué es un worktree?
Un worktree es un directorio de trabajo vinculado a tu repositorio.
Cada worktree tiene sus propios archivos, área de staging y HEAD, que identifica el commit o la rama en la que estás trabajando. Los worktrees comparten los objetos de Git y las referencias de las ramas.
Puedes organizarte así:
carpeta-de-practicas/
├── taller-git-worktrees/ → feature/nuevo-menu
└── taller-git-hotfix/ → hotfix/contacto
Compartir repositorio no significa que los cambios se integren automáticamente entre ramas. Un commit creado en el hotfix estará disponible en el historial compartido, pero la otra rama conservará su versión de los archivos hasta que incorpores ese cambio.
Puedes consultar este modelo en la documentación oficial de Git worktree.
Qué vamos a conseguir
Al terminar tendrás:
- Una funcionalidad con trabajo pendiente en su propia carpeta.
- Una corrección guardada en otra rama.
- La comprobación de que atender el hotfix no modificó el trabajo pendiente.
- Un procedimiento para retirar el worktree cuando termines.
No necesitas instalar dependencias ni levantar una aplicación.
Antes de empezar
Necesitas Git, un editor y GitKraken Desktop con soporte para worktrees, disponible desde la versión 10.5 según su documentación oficial.
Los comandos están preparados para Bash, Zsh o Git Bash en Windows. Usa una carpeta nueva, fuera de tus proyectos habituales.
Combinaremos la terminal para preparar el laboratorio con GitKraken para revisar los cambios y crear el commit de la corrección.
1. Prepara una funcionalidad a medias
Ejecuta:
mkdir taller-git-worktrees
cd taller-git-worktrees
git init -b main
git config user.name "Demo Git"
git config user.email "demo@example.com"
printf 'Contacto: soporte pendiente\n' > contacto.txt
git add contacto.txt
git commit -m "chore: crear portal de ejemplo"
git switch -c feature/nuevo-menu
printf 'Menú en construcción\n' > menu.txt
La identidad de ejemplo queda configurada únicamente para este repositorio.
Ahora tienes una rama llamada feature/nuevo-menu y un archivo menu.txt sin commit. Este archivo representa la funcionalidad que estabas desarrollando cuando llegó la urgencia.
Abre la carpeta taller-git-worktrees en GitKraken. Comprueba que la rama activa sea feature/nuevo-menu y que aparezca el archivo pendiente.
También puedes verificarlo en la terminal:
git status --short
El resultado debe incluir:
?? menu.txt
Los signos ?? indican que Git todavía no está siguiendo ese archivo.
2. Crea un worktree para el hotfix
La urgencia consiste en corregir el contacto de soporte. Queremos partir de main, sin incluir la funcionalidad incompleta.
Desde la misma terminal, ejecuta:
git worktree add -b hotfix/contacto ../taller-git-hotfix main
git worktree list
El primer comando hace tres cosas:
- Crea la rama
hotfix/contacto. - Usa
maincomo punto de partida. - Prepara los archivos de esa rama en
../taller-git-hotfix.
El segundo comando muestra las carpetas vinculadas y la rama activa en cada una.
Tu archivo menu.txt sigue pendiente en la carpeta original. No necesitamos guardarlo en un commit ni retirarlo para comenzar la corrección.
¿También se puede crear desde GitKraken?
Sí. Para hacerlo visualmente, prepara una rama que no esté activa en otro worktree, haz clic derecho sobre ella y selecciona Create worktree.
En este laboratorio ya lo creamos desde la terminal. Ahora solo ábrelo desde el panel izquierdo de GitKraken, usando Open this worktree o Open worktree in a new tab. El procedimiento visual está documentado aquí.
3. Corrige desde la carpeta del hotfix
En la terminal, entra al nuevo directorio y comprueba la rama:
cd ../taller-git-hotfix
git branch --show-current
El resultado debe ser:
hotfix/contacto
Actualiza el archivo y revisa la diferencia:
printf 'Contacto: soporte@example.com\n' > contacto.txt
git diff
El cambio esperado es:
-Contacto: soporte pendiente
+Contacto: soporte@example.com
En GitKraken:
- Abre el worktree del hotfix.
- Confirma que estás en
hotfix/contacto. - Revisa el diff de
contacto.txt. - Pasa únicamente ese archivo a staging.
- Crea el commit con este mensaje:
fix: corregir contacto de soporte
El correo utilizado es ficticio.
4. Regresa y comprueba que conservaste tu contexto
Vuelve al directorio original:
cd ../taller-git-worktrees
git status --short
cat menu.txt
cat contacto.txt
Debes encontrar:
-
menu.txttodavía sin commit. - El texto
Menú en construcciónintacto. - El contacto original:
Contacto: soporte pendiente.
Este último punto es importante: la corrección quedó guardada en hotfix/contacto, pero todavía no está integrada en feature/nuevo-menu.
Los worktrees nos permitieron trabajar en dos contextos independientes. La integración entre ramas sigue siendo una decisión explícita.
5. Termina el laboratorio y retira el worktree
Para cerrar la práctica, guardaremos el borrador del menú en su rama:
git add menu.txt
git commit -m "feat: agregar borrador del menú"
Ahora integra la corrección en main:
git switch main
git merge --ff-only hotfix/contacto
En este laboratorio main no recibió otros commits, así que puede avanzar directamente hasta el commit del hotfix.
Antes de retirar la carpeta, comprueba que no tenga cambios pendientes:
git -C ../taller-git-hotfix status --short
Si no muestra nada, puedes continuar:
git worktree remove ../taller-git-hotfix
git branch -d hotfix/contacto
git worktree list
git worktree remove retira el directorio de trabajo vinculado. La eliminación de la rama es una operación separada, que hacemos después de integrarla.
Al terminar:
-
maincontiene el contacto corregido. -
feature/nuevo-menuconserva el commit del menú. - La carpeta temporal del hotfix ya no es necesaria.
En un repositorio compartido, publica la rama y sigue el proceso de pull request, revisión y validación del equipo antes de dar por integrada la corrección.
Lo que debes considerar en una aplicación real
Un worktree separa los archivos de trabajo, pero no configura automáticamente un entorno completo e independiente.
Si ejecutas dos versiones de tu aplicación, revisa:
- Dependencias: cada carpeta puede necesitar su propia instalación.
-
Variables locales: los archivos ignorados, como
.env, no se copian automáticamente desde la otra carpeta. - Puertos: dos servidores no pueden escuchar simultáneamente en la misma dirección y puerto.
- Bases de datos y servicios: ambas instancias podrían conectarse al mismo recurso externo.
Además, Git normalmente impide activar una misma rama en dos worktrees. Utiliza una rama distinta por tarea.
¿Cuándo conviene usar este flujo?
Es especialmente útil cuando necesitas mantener dos contextos disponibles durante un tiempo: atender un hotfix, revisar otra rama o comparar implementaciones.
Para una pausa breve, git stash también puede ser suficiente. La ventaja del worktree aparece cuando quieres conservar las carpetas abiertas y moverte entre ellas sin reemplazar continuamente sus archivos.
GitKraken te permite seguir visualmente qué rama estás revisando y qué cambios estás guardando. El hábito sigue siendo el mismo: confirma carpeta, rama y diff antes de cada commit.
Reto para practicar
Desde main, crea otra rama con su propio worktree para escribir documentación.
Agrega un archivo sin hacer commit y comprueba que:
- Aparece como pendiente en el nuevo worktree.
- No aparece en el directorio original.
- Puedes identificar ambas carpetas con
git worktree list.
Después guarda el cambio y decide si quieres integrarlo o conservarlo en su rama antes de retirar el worktree.
¿Para qué usarías primero este flujo: atender un hotfix, revisar un pull request o probar una idea?
Top comments (0)