Git Flow en la práctica: feature, release y hotfix

Git Flow es un modelo de branches que propuso Vincent Driessen en 2010. La idea es simple: cada branch tiene un papel fijo. Así queda claro qué está en producción, qué va a entrar en la próxima versión y qué es una corrección urgente.

En esta guía vas a ver para qué sirve cada branch, los comandos de cada flujo, cómo nombrar branches y versiones, los errores más comunes y en qué tipo de proyecto el modelo realmente ayuda.

Los branches de Git Flow

• main: lo que está en producción. Cada merge aquí se convierte en una versión, marcada con un tag.
• develop: donde se juntan las features antes de la próxima versión.
• feature/*: salen de develop y vuelven a develop cuando están listas.
• release/*: salen de develop para preparar una versión. Vuelven a main y a develop.
• hotfix/*: salen de main para corregir producción. Vuelven a main y a develop.

main y develop viven para siempre. Las demás son temporales: nacen, cumplen su papel y se borran.

El flujo de una feature

Una feature nace de develop, recibe los commits del trabajo y vuelve a develop con un merge:

git switch develop
git pull
git switch -c feature/login-sso
# commits de la feature
git switch develop
git merge --no-ff feature/login-sso
git branch -d feature/login-sso
git push origin develop

El --no-ff crea un commit de merge incluso cuando Git podría solo avanzar el puntero. Así el historial muestra dónde empezó y dónde terminó la feature, lo que ayuda mucho al revisar o revertir la feature completa.

En equipos que usan pull requests, el merge en develop suele hacerse en GitHub, GitLab o Azure DevOps, después de la revisión. La lógica es la misma.

Cerrar una release

Cuando develop tiene lo que debe salir en la próxima versión, abre un branch de release. Desde ese momento el alcance queda congelado: solo entran correcciones, el ajuste del número de versión y el changelog.

git switch -c release/1.4.0 develop
# ajustes finales, versión y changelog
git switch main
git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Versión 1.4.0"
git switch develop
git merge --no-ff release/1.4.0
git branch -d release/1.4.0
git push origin main develop --tags

Mientras la release está abierta, el equipo puede seguir abriendo features en develop. Esas entran en la versión siguiente.

Corregir producción con un hotfix

El hotfix sigue la misma lógica, pero parte de main, porque tiene que corregir exactamente lo que está en producción:

git switch -c hotfix/1.4.1 main
# corrección
git switch main
git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Versión 1.4.1"
git switch develop
git merge --no-ff hotfix/1.4.1
git branch -d hotfix/1.4.1

Llevar la corrección a develop es el paso que más se olvida. Es el que evita que el bug vuelva en la versión siguiente. Si hay una release abierta, lleva el hotfix a ella en lugar de a develop.

Nombres de branch y versiones

• Usa prefijos fijos: feature/, release/ y hotfix/. Las herramientas y los pipelines dependen de ellos.
• En la feature, describe el tema o usa el número de la tarea: feature/login-sso o feature/1234-login-sso.
• En la release y en el hotfix, usa el número de versión: release/1.4.0 y hotfix/1.4.1.
• Sigue el versionado semántico: el tercer número sube con correcciones, el segundo con novedades compatibles y el primero con cambios que rompen la compatibilidad.

¿Git Flow, GitHub Flow o trunk-based?

• Git Flow: bueno para productos con versiones numeradas, apps de escritorio y móviles, bibliotecas y sistemas que mantienen más de una versión en paralelo.
• GitHub Flow: solo main y branches cortos con pull request. Bueno para aplicaciones web que se publican varias veces por semana.
• Trunk-based: todos integran en main varias veces al día, con feature flags para ocultar lo que no está listo. Bueno para equipos maduros con pruebas automatizadas sólidas.

No existe un modelo correcto para todos. Si tu equipo publica en producción varias veces al día, Git Flow te va a parecer burocrático. Si entregas versiones para que los clientes las instalen, ordena mucho el trabajo.

Los errores más comunes

• Olvidar llevar el hotfix de vuelta a develop.
• Dejar la release abierta por semanas, hasta que se convierte en una segunda develop.
• Features que viven mucho tiempo sin recibir develop y acumulan conflictos.
• Hacer commits directo en main o en develop, sin pasar por un branch.
• Olvidar crear el tag, lo que deja la versión en producción sin referencia en el historial.

Git Flow en GitMuninn

En el plan Pro, GitMuninn inicia y termina features, releases y hotfixes con los prefijos que tu repositorio ya usa, sin que tengas que memorizar la secuencia de comandos. Y como cada branch tiene un color en el grafo, es fácil ver si un hotfix ya volvió a develop o si una release sigue abierta.