Git Flow: qué es, modelo de ramificación y uso en proyectos

¿Qué es Git Flow?

Git Flow es un modelo de ramificación de Git que define una estructura estricta de ramas y reglas de fusión para gestionar el desarrollo, los lanzamientos y las correcciones. Vincent Driessen publicó el artículo “A successful Git branching model” en enero de 2010, y desde entonces Git Flow se ha convertido en el estándar de facto en el desarrollo empresarial Java y .NET. La idea principal es dividir el código en cinco tipos de ramas con diferentes niveles de estabilidad.

Según Atlassian Git Tutorials, 2024, Git Flow se basa en dos ramas perpetuas: main (anteriormente master) y develop. Todas las demás ramas son temporales: feature, release, hotfix. Cada tipo de rama tiene un ciclo de vida y reglas de fusión claramente definidos. En el desarrollo móvil, Git Flow se utiliza en proyectos con ciclos de lanzamiento regulares (2–4 semanas) y soporte para múltiples versiones.

Git Flow se diferencia de los modelos simples (GitHub Flow) al requerir una rama develop separada para la integración. Esto añade un paso al proceso de fusión, pero proporciona un aislamiento adicional de las características incompletas del código listo para el lanzamiento.

Vincent Driessen y la historia de Git Flow

En 2010, Vincent Driessen publicó el post “A successful Git branching model”, que se convirtió en uno de los más citados en la historia de Git. El modelo fue creado para un proyecto con lanzamientos fijos y soporte paralelo de versiones. En 2020, Driessen reconoció que Git Flow está desactualizado para las prácticas modernas de CI/CD, pero el modelo sigue siendo relevante para proyectos con ciclos de lanzamiento largos y la necesidad de soportar versiones antiguas.

# Inicializar Git Flow
git flow init

# Crear una rama feature
git flow feature start "add-auth"

# Finalizar rama feature (fusionar en develop)
git flow feature finish "add-auth"

# Crear un release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Rama Main: código de lanzamiento y etiquetado

Main (anteriormente master) es la rama principal que contiene solo el código de lanzamiento listo para el despliegue. Cada commit en main debe corresponder a una versión específica del producto, etiquetada con el formato de versionado semántico, por ejemplo, v1.0.0, v1.1.0. No se realiza ningún desarrollo directo en main: los cambios llegan aquí solo a través de las ramas release o hotfix.

Según semver.org, 2024, las etiquetas en main usan el formato MAJOR.MINOR.PATCH. MAJOR se incrementa para cambios incompatibles en la API, MINOR para añadidos de funcionalidad con compatibilidad hacia atrás, PATCH para correcciones de errores. En Git Flow, cada finalización de release crea automáticamente un commit en main con una etiqueta de versión.

La rama Main es la única que se despliega en producción. Para proyectos móviles, esto significa que un push a main activa el pipeline de compilación de App Bundle o IPA y la publicación en Google Play / App Store. En la configuración de CI/CD de GitLab, main está protegida contra force-push y eliminación.

Versionado semántico y etiquetas

Cada commit en main va acompañado de una etiqueta en formato SemVer: vMAJOR.MINOR.PATCH. MAJOR — para cambios incompatibles en la API, MINOR — para nueva funcionalidad con compatibilidad hacia atrás, PATCH — para correcciones de errores. Ejemplo: v2.1.0 significa el segundo lanzamiento importante con nuevas funciones y sin correcciones de errores. En Git Flow, las etiquetas se crean automáticamente al finalizar un release o hotfix mediante el comando git flow release finish.

Rama Develop: línea de integración del desarrollo

Develop es la segunda rama perpetua en Git Flow, diseñada para integrar todas las funcionalidades completadas. Los desarrolladores fusionan las ramas feature en develop después de pasar la revisión de código y las comprobaciones de CI/CD. Develop contiene la última versión estable del código, incluyendo todas las funcionalidades implementadas del sprint actual.

Según DataSift Git Flow Guide, 2024, develop puede ser temporalmente inestable debido a integraciones en curso. Para prevenir problemas, los equipos practican Integración Continua (CI): cada funcionalidad debe pasar un conjunto completo de pruebas antes de fusionarse en develop. Si la CI falla, el desarrollador corrige el código antes de la siguiente fusión. Develop siempre está vinculada a la versión actual de main: inmediatamente después de un lanzamiento, develop se sincroniza con main mediante una fusión.

Ramas Feature: desarrollo de nueva funcionalidad

Las ramas feature son ramas temporales para desarrollar funcionalidades individuales, correcciones de errores o experimentos. Cada rama feature se crea desde develop y se fusiona de vuelta a develop al completarse. El nombre de la rama feature suele contener el número de la tarea o una breve descripción: feature/APP-123-add-oauth, feature/redesign-profile. En Git Flow, las ramas feature pueden existir indefinidamente.

Según Pro Git Book, 2024, las ramas feature son un entorno de desarrollo aislado: los cambios en una rama no afectan a otras hasta la fusión. En proyectos móviles, las ramas feature se sincronizan con develop mediante rebase o merge para evitar grandes conflictos al finalizar. Se recomienda hacer rebase de la rama feature sobre develop antes de crear un MR.

# Creación manual de rama feature (sin git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Crear MR en GitLab mediante CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Ramas Release: preparación de un lanzamiento

Las ramas release son ramas temporales creadas desde develop para preparar un lanzamiento. Cuando develop contiene suficientes funcionalidades para una nueva versión, el equipo crea una rama release/X.Y.Z (por ejemplo, release/2.1.0). En esta rama solo se realizan cambios finales: aumento de versión, actualización de localización, pruebas finales, corrección de errores críticos.

Según Atlassian Git Tutorials, 2024, la rama release resuelve un problema clave: aislar los cambios finales del desarrollo paralelo. Mientras se prepara el lanzamiento, nuevas funcionalidades para el próximo lanzamiento continúan fusionándose en develop. Tras completarse, la rama release se fusiona en main (con una etiqueta) y en develop (para sincronizar el aumento de versión).

Ramas Hotfix: correcciones urgentes en producción

Las ramas hotfix son ramas temporales para corregir urgentemente errores críticos en producción. El único tipo de rama en Git Flow que se crea desde main en lugar de develop. Formato del nombre: hotfix/X.Y.Z+1 (por ejemplo, hotfix/2.1.1). Tras completarse, la rama hotfix se fusiona simultáneamente en main (como un nuevo parche) y en develop (para que la corrección no se pierda en futuros lanzamientos).

Según DataSift Git Flow Guide, 2024, las ramas hotfix deben ser lo más cortas posible — solo la corrección y las pruebas. Un hotfix no debe incluir nuevas funcionalidades ni refactorización. En el desarrollo móvil, los hotfix se utilizan para fallos críticos (tasa de crash > 0.1%), vulnerabilidades de seguridad o errores bloqueantes en App Store.

Ventajas y desventajas de Git Flow para el desarrollo móvil

Git Flow proporciona una estructura clara que es especialmente útil para equipos grandes y proyectos con lanzamientos regulares. Ventajas: aislamiento de funcionalidades incompletas en ramas feature, posibilidad de preparar un lanzamiento sin bloquear el desarrollo, soporte para múltiples versiones mediante hotfix. Desventajas: complejidad para principiantes, necesidad de rebase regular de las ramas feature, conflictos con ramas de larga duración.

Según Martin Fowler, 2024, el principal inconveniente de Git Flow son las ramas feature de larga duración. Si una funcionalidad se desarrolla durante 2+ semanas sin sincronización con develop, el conflicto de fusión se vuelve significativo. Para proyectos móviles, se recomienda sincronizar la rama feature diariamente mediante rebase sobre develop.

Git Flow no se recomienda para proyectos con Continuous Deployment (cada commit en main → producción). Para tales proyectos, GitHub Flow o Trunk-Based Development ofrecen un modelo más simple y rápido. Pero para proyectos con ciclos de lanzamiento y soporte de versiones antiguas, Git Flow sigue siendo la opción óptima.

Cuándo Git Flow es perjudicial para el equipo

Git Flow se convierte en un problema en tres casos: equipos de menos de 5 personas (complejidad innecesaria), Continuous Deployment (retraso en la entrega), falta de disciplina de rebase (las ramas feature de larga duración crean conflictos de fusión). Si un equipo dedica más del 20% del tiempo a fusionar ramas y resolver conflictos, Git Flow no es adecuado para ese equipo, incluso si es grande.

Alternativas a Git Flow: GitHub Flow y Trunk-Based Development

Las alternativas a Git Flow ofrecen un proceso más simple para equipos que practican CI/CD. GitHub Flow utiliza solo una rama perpetua (main) y ramas feature. Cada funcionalidad se crea desde main, tras la revisión y CI se fusiona de vuelta a main y se despliega inmediatamente. GitHub Flow es más simple pero no soporta el aislamiento de funcionalidades incompletas ni la preparación paralela de lanzamientos.

Según GitHub Docs, 2024, Trunk-Based Development (TBD) va aún más allá: todos los desarrolladores trabajan en una sola rama (trunk), utilizando ramas feature de corta duración de 1–2 días. Los feature toggles controlan la visibilidad del código incompleto. TBD requiere una alta disciplina de CI/CD y automatización de pruebas.

• GitHub Flow — una main + ramas feature, ideal para CI/CD y equipos pequeños
• GitLab Flow — extiende Git Flow con ramas de entorno (staging, production)
• Trunk-Based Development — una rama + feature toggles, máximo CI/CD, mínimas fusiones
• One Flow — Git Flow simplificado sin rama develop, solo main + feature + release