Flujo de trabajo Gitflow

Descripción general

Gitflow es un modelo de ramificación estructurado, popularizado por Vincent Driessen en 2010, diseñado para proyectos con lanzamientos programados y versionados. En lugar de una única rama de integración, utiliza dos ramas de larga duración más tres tipos de ramas de soporte, cada una con un propósito definido. La estructura hace que la gestión de lanzamientos sea explícita, aunque con mayor ceremonia.

Las dos ramas de larga duración

Estas dos ramas existen durante toda la vida del proyecto — nunca se eliminan.

• main contiene el código listo para producción. Cada commit en main corresponde a una versión publicada y normalmente está etiquetado (por ejemplo, v1.4.0). Si quieres saber exactamente qué está en producción, haces checkout de main.
• develop es la rama de integración donde las funcionalidades completadas se acumulan entre lanzamientos. Siempre contiene los últimos cambios entregados destinados al próximo lanzamiento, aunque esos cambios no son necesariamente estables aún.

Dado que ambas ramas son permanentes, la relación entre ellas nunca se reinicia: develop siempre va "por delante" de main en todo lo que aún no se ha publicado.

Las tres ramas de soporte

Las ramas de soporte son de corta duración. Cada una se crea con un propósito, se fusiona cuando ese propósito se cumple y luego se elimina. Las convenciones de nomenclatura (feature/, release/, hotfix/) hacen que su función sea obvia en la salida de git branch.

Ramas de funcionalidad (feature)

Las ramas de funcionalidad se crean a partir de develop y se fusionan de vuelta en develop. Contienen el trabajo para una funcionalidad próxima y nunca interactúan directamente con main — una sola funcionalidad nunca se publica por sí sola; se lanza como parte del próximo lanzamiento versionado.

git switch develop
git switch -c feature/search   # create + check out feature/search
# ...work and commit...
git switch develop
git merge feature/search       # fold the feature into develop
git branch -d feature/search   # delete it once merged

git switch -c <name> crea la rama a partir de la rama actual y hace checkout en un solo paso — es el equivalente moderno de git checkout -b. Consulta Git switch para el comando completo. Mantener las ramas de funcionalidad de corta duración limita cuánto se alejan de develop, lo que reduce los conflictos de fusión.

Ramas de lanzamiento (release)

Las ramas de lanzamiento se crean a partir de develop cuando este tiene las funcionalidades completas para un lanzamiento. Existen solo para los últimos ajustes — actualizaciones de versión, notas de lanzamiento y correcciones de errores de última hora — mientras que develop permanece abierto para las funcionalidades del siguiente ciclo.

Cuando el lanzamiento está listo, la rama se fusiona en ambos lugares:

• en main, donde se etiqueta con el número de versión; y
• de vuelta en develop, para que las correcciones de estabilización realizadas en la rama de lanzamiento no se pierdan.

git switch -c release/1.4.0 develop
# ...bump version, fix last bugs, write release notes...
git switch main
git merge --no-ff release/1.4.0      # record an explicit merge commit
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop
git merge --no-ff release/1.4.0      # carry fixes back into develop
git branch -d release/1.4.0

--no-ff (sin avance rápido) obliga a Git a crear un commit de fusión incluso cuando es posible un avance rápido, de modo que el lanzamiento queda preservado como un punto único y visible en el historial en lugar de desaparecer aplastado.

Ramas de corrección urgente (hotfix)

Las ramas de corrección urgente se crean a partir de main para parchear un error en producción de forma urgente — sin esperar a que el trabajo actual en develop esté listo para publicarse. Al igual que las ramas de lanzamiento, se fusionan en ambos: main (etiquetado con una versión de parche incrementada) y develop, de modo que la corrección también esté presente en futuros lanzamientos.

git switch -c hotfix/1.4.1 main
# ...fix the bug and commit...
git switch main
git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Hotfix 1.4.1"
git switch develop
git merge --no-ff hotfix/1.4.1       # don't reintroduce the bug later
git branch -d hotfix/1.4.1

Olvidar la segunda fusión — de vuelta en develop — es el error clásico de Gitflow: el error reaparece en el siguiente lanzamiento porque la corrección solo llegó a main.

Cuándo usar Gitflow

Gitflow brilla cuando publicas lanzamientos distintos y versionados — aplicaciones de escritorio, bibliotecas, aplicaciones móviles sometidas a revisión en tiendas de aplicaciones, o cualquier cosa con números de versión mantenidos y parches de emergencia ocasionales. Las ramas de lanzamiento y de corrección urgente explícitas te dan un lugar claro para estabilizar y corregir producción sin interrumpir el desarrollo en curso. La necesidad de mantener varias versiones publicadas a la vez es la señal más fuerte de que la estructura de Gitflow valdrá la pena.

Un ciclo de lanzamiento completo de un vistazo

Uniendo las piezas, una versión pasa por las ramas así:

1. Los desarrolladores crean ramas feature/* a partir de develop, construyen y fusionan cada una de vuelta en develop.
2. Cuando develop tiene suficiente para un lanzamiento, se crea una rama release/x.y.0 para la estabilización final.
3. La rama de lanzamiento se fusiona en main, se etiqueta como vx.y.0 y se fusiona de vuelta en develop.
4. Si la producción falla, se crea un hotfix/x.y.z a partir de main, se etiqueta y se fusiona en main y en develop.

main por lo tanto solo avanza mediante fusiones de lanzamiento y de corrección urgente, y cada commit en ella es una versión publicable y etiquetada.

Las ventajas y desventajas

Esa estructura es también la debilidad de Gitflow. Los numerosos tipos de ramas añaden sobrecarga, y la rama develop de larga duración puede alejarse mucho de main, lo que hace dolorosas las fusiones. Las ramas de larga duración fomentan integraciones grandes e infrecuentes — lo contrario de lo que busca la entrega continua. Los equipos que publican muchas veces al día suelen encontrar Gitflow demasiado pesado y prefieren el enfoque más simple de ramas de funcionalidad o desarrollo basado en trunk, donde el trabajo se integra en una sola rama de forma continua. Elige Gitflow cuando la cadencia de lanzamientos y el soporte de versiones paralelas, y no la velocidad de despliegue, sean tus prioridades.

Compáralo con las alternativas antes de comprometerte: el flujo de trabajo con fork para contribuciones de código abierto, y las ramas de funcionalidad simples para la mayoría de las aplicaciones web que se despliegan desde una única línea.

Práctica