Git Flow, GitHub Flow y trunk-based: qué flujo de trabajo de Git elegir

Qué es un flujo de trabajo de Git y por qué importa elegirlo

Un flujo de trabajo de Git (Git workflow) es el acuerdo del equipo sobre qué ramas existen, de dónde se crean, dónde se fusionan y qué se considera listo para publicar. Git no impone nada de esto, así que sin un acuerdo cada uno trabaja a su manera, y al cabo de un mes el repositorio tiene decenas de ramas, nadie sabe qué está desplegado y las fusiones se convierten en horas de conflictos.

Los modelos más conocidos son Git Flow, GitHub Flow (una variante del Feature Branch Workflow) y el trunk-based development. No son «lo viejo y lo nuevo», sino herramientas para condiciones distintas: con qué frecuencia publicas, cuántas versiones del producto mantienes a la vez y lo maduros que son tus tests automáticos.

Git Flow: el modelo con ramas develop y release

Git Flow lo describió Vincent Driessen en 2010. El modelo se apoya en dos ramas de larga vida:

• main (en proyectos antiguos, master): solo código publicado; cada commit aquí corresponde a una versión y se marca con una etiqueta;
• develop: la rama de integración, donde se fusionan las funcionalidades terminadas para la próxima versión.

Y en tres tipos de ramas temporales:

Git Flow con Git puro

El ciclo de una funcionalidad y una release es así:

# funcionalidad
git switch develop
git switch -c feature/cart-discounts
# ... commits ...
git switch develop
git merge --no-ff feature/cart-discounts
git branch -d feature/cart-discounts

# release
git switch -c release/1.4.0 develop
# ... cambio de versión y correcciones ...
git switch main
git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop
git merge --no-ff release/1.4.0
git branch -d release/1.4.0

La opción --no-ff es fundamental en este modelo: crea un commit de merge incluso cuando sería posible un avance rápido, y así en el historial se ve qué commits pertenecían a una misma funcionalidad o release.

La extensión git-flow

Para no teclear estas secuencias a mano existe la herramienta git-flow (hoy se suele instalar un fork mantenido, que en los gestores de paquetes a menudo se llama git-flow-avh). Añade subcomandos:

git flow init -d
git flow feature start cart-discounts
git flow feature finish cart-discounts
git flow release start 1.4.0
git flow release finish 1.4.0
git flow hotfix start 1.4.1
git flow hotfix finish 1.4.1

git flow init pregunta los nombres de las ramas y los prefijos (con -d acepta los valores por defecto), y los comandos finish hacen todas las fusiones necesarias, ponen la etiqueta y borran la rama temporal. Muchos clientes gráficos de Git también permiten trabajar con Git Flow mediante botones.

Ventajas e inconvenientes de Git Flow

Ventajas: estructura clara, estado del código evidente (main es lo que tienen los clientes; develop, la siguiente versión), una fase separada de estabilización y un soporte cómodo para hotfixes. Encaja bien en aplicaciones móviles, software empaquetado, librerías y firmware, donde la versión pasa la revisión de la tienda de aplicaciones o se instala en casa del cliente.

Inconvenientes: muchas ramas y fusiones, las ramas de funcionalidad de larga vida acumulan divergencias con develop y es fácil olvidar las fusiones dobles de release y hotfix. Para un servicio web que se despliega varias veces al día, las ramas release se convierten en burocracia. El propio autor del modelo añadió en 2020 una nota a su artículo: para software de entrega continua conviene mirar enfoques más simples como GitHub Flow.

GitHub Flow: ramas cortas y pull requests

GitHub Flow es una versión ligera del Feature Branch Workflow. Sus reglas caben en unos pocos puntos:

1. main siempre funciona y está lista para desplegar.
2. Todo el trabajo se hace en una rama desde main con un nombre descriptivo.
3. La rama se sube con regularidad y se abre un pull request (merge request) para discutirla.
4. Tras la revisión y con el CI en verde, la rama se fusiona en main.
5. Lo que entra en main se despliega de inmediato.

git switch main
git pull
git switch -c feature/new-payment
# ... commits con mensajes claros ...
git push -u origin feature/new-payment
# abrimos un pull request, pasamos revisión y CI, fusionamos en main

Ventajas: una sola rama de larga vida, reglas mínimas, camino rápido de la idea a producción y revisión de código natural. Inconvenientes: no hay un lugar previsto para mantener varias versiones ni para estabilizar antes de publicar, y sin buenos tests automáticos «main siempre lista» se queda en un deseo.

A un enfoque parecido con ramas de entorno adicionales (por ejemplo, staging y production) a veces se le llama GitLab Flow. Es útil cuando el despliegue a producción no es inmediato, sino programado o tras una verificación manual.

Trunk-based development

En el trunk-based development todos los desarrolladores integran sus cambios en una sola rama (trunk, es decir, main) con frecuencia: al menos una vez al día. Si hay ramas, duran horas, no semanas. La funcionalidad sin terminar entra en main, pero oculta tras un feature flag:

if (featureFlags.isEnabled("new-checkout", user)) {
    renderNewCheckout();
} else {
    renderOldCheckout();
}

La gran ventaja es la casi total ausencia de conflictos graves: los cambios son pequeños y se fusionan mientras todos recuerdan el contexto. El modelo practica la integración continua en sentido literal y encaja con equipos maduros que tienen un CI rápido y buena cobertura de tests. Se admiten ramas de release, pero se crean desde trunk justo antes de publicar, y las correcciones se hacen primero en trunk y luego se llevan con cherry-pick.

Inconvenientes: exige disciplina e infraestructura (tests rápidos, flags, monitorización). A un principiante le da miedo hacer commit en main todos los días, y un CI débil convierte el trunk en una rama rota permanentemente. Los flags también hay que eliminarlos a tiempo, o el código se llena de bifurcaciones muertas.

Comparativa: Git Flow, GitHub Flow y trunk-based

Cómo elegir el flujo de trabajo de Git para tu equipo

Responde a unas cuantas preguntas:

• ¿Hay que mantener varias versiones publicadas? Si hay clientes en 2.x y en 3.x y ambas necesitan correcciones: Git Flow o trunk-based con ramas release.
• ¿Con qué frecuencia despliegas? Una vez por trimestre: Git Flow no estorbará. Cada día: elige GitHub Flow o trunk-based.
• ¿Cuánto confías en tus tests? Si el CI es lento y la cobertura floja, empieza con GitHub Flow con revisión obligatoria y ve acortando las ramas poco a poco.
• ¿Qué tamaño y experiencia tiene el equipo? Para un equipo pequeño y para principiantes lo más fácil es GitHub Flow: una sola regla, «main siempre funciona», y pull request para todo.

Consejo práctico: no adoptes Git Flow «porque es lo que se hace». Empieza por el proceso más simple que resuelva tus necesidades y complícalo solo cuando aparezca un problema concreto, por ejemplo, cuando haga falta una fase de estabilización o mantener versiones antiguas.

Reglas que funcionan en cualquier flujo

• Protege main en el servidor: prohíbe el push directo y exige revisiones y CI en verde antes de fusionar.
• Poneos de acuerdo en los nombres de rama: feature/, fix/, hotfix/ más el número de tarea.
• Mantén las ramas cortas: cuanto más vive una rama, más duele fusionarla. Trae main a tu rama con regularidad mediante merge o rebase.
• Elige una estrategia de fusión para los pull requests (merge commit, squash o rebase) y úsala de forma uniforme.
• Marca las versiones con etiquetas anotadas siguiendo el versionado semántico.

Un hotfix en cada modelo: un bug, tres procesos

La diferencia entre los enfoques se ve mejor con una corrección urgente en producción.

En Git Flow se crea hotfix/1.4.1 desde main; tras la corrección, la rama se fusiona en main con la etiqueta v1.4.1 y, obligatoriamente, en develop (o en la rama release actual, si existe). Olvidar la segunda fusión es un error clásico: en la siguiente versión el bug «vuelve».

git switch -c hotfix/1.4.1 main
git commit -am "Corregir el cálculo del descuento"
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

En GitHub Flow el hotfix es una rama corta normal desde main con un pull request al que se da prioridad en la revisión. Tras la fusión llega a producción con el mismo despliegue automático; no hay un proceso aparte.

En trunk-based la corrección se hace primero en trunk y, si en producción corre una rama release, el commit se lleva a ella con git cherry-pick -x <hash>. La opción -x añade al mensaje una referencia al commit original para que la relación quede visible en el historial. Y si el problema está en una funcionalidad nueva, a menudo basta con apagar su feature flag sin tocar el código.

Cómo responder en una entrevista a «qué flujo de Git habéis usado»

El entrevistador no comprueba si conoces los nombres, sino si entiendes los compromisos. Una buena respuesta nombra el modelo, describe cómo se organizaban las ramas y la revisión y explica por qué encajaba con el proyecto. Por ejemplo: «Usábamos GitHub Flow: ramas desde main, pull request con revisión obligatoria y CI, y despliegue automático tras la fusión. No elegimos Git Flow porque publicábamos varias veces por semana y las ramas release solo nos habrían frenado». Punto extra si cuentas qué cambiarías si el proceso creciera.

Resumen

Git Flow es un modelo estricto con ramas develop, release y hotfix, adecuado para productos con versiones planificadas y soporte de varias releases. GitHub Flow es más simple y sirve a la mayoría de proyectos web, y el trunk-based development da la máxima velocidad, pero exige un CI maduro y feature flags. Elige tu flujo de trabajo de Git según la frecuencia de publicación y la calidad de los tests, no por moda. Los tres enfoques, con sus comandos y errores típicos, se practican en el curso de Git.