GitFlow

GitFlow es un modelo de branching que asigna roles específicos a las ramas y define cómo y cuándo interactúan. Fue propuesto por Vincent Driessen en 2010 y se convirtió en el estándar para equipos con releases programados.

¿Cómo funciona?

Ramas permanentes

• main — siempre refleja el código en producción. Cada commit es un release.
• develop — rama de integración. Aquí se acumulan features terminados para el próximo release.

Ramas temporales

• feature/* — una por feature, nace de develop, se mergea de vuelta a develop
• release/* — preparación del release, nace de develop, se mergea a main y develop
• hotfix/* — corrección urgente en producción, nace de main, se mergea a main y develop

Flujo visual

main:     ──●──────────────────●──────────●──
              \               / \        / \
release:       \        ──●──●   \      /   \
                \       /         \    /     \
develop:  ──●────●────●────●───●───●──●───●───●──
              \      /   \      /
feature:       ●──●──●    ●──●──●

Ejemplo completo

# 1. Iniciar un feature
git checkout develop
git checkout -b feature/user-auth
 
# ... trabajar, hacer commits ...
git commit -m "feat: add login form"
git commit -m "feat: add JWT validation"
 
# 2. Terminar el feature
git checkout develop
git merge --no-ff feature/user-auth
git branch -d feature/user-auth
 
# 3. Preparar release
git checkout develop
git checkout -b release/1.2.0
 
# ... solo bug fixes y preparación ...
git commit -m "fix: typo in login page"
git commit -m "chore: bump version to 1.2.0"
 
# 4. Publicar release
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0 -m "Release 1.2.0"
 
git checkout develop
git merge --no-ff release/1.2.0
git branch -d release/1.2.0
 
# 5. Hotfix urgente
git checkout main
git checkout -b hotfix/1.2.1
 
git commit -m "fix: critical security vulnerability"
 
git checkout main
git merge --no-ff hotfix/1.2.1
git tag -a v1.2.1 -m "Hotfix 1.2.1"
 
git checkout develop
git merge --no-ff hotfix/1.2.1
git branch -d hotfix/1.2.1

¿Cuándo usarlo?

Buena opción cuando:

• Releases programados (cada 2 semanas, mensual, etc.)
• Múltiples versiones en producción simultáneamente
• Equipo grande con features paralelos que necesitan integración controlada
• Software con ciclo QA formal antes de cada release
• Productos con soporte a largo plazo (LTS)

Evitar cuando:

• Continuous deployment — si haces deploy varias veces al día, GitFlow agrega fricción innecesaria
• Equipo pequeño (1-5 personas) — la ceremonia no justifica el overhead
• Aplicaciones web con un solo entorno de producción
• Proyectos que priorizan velocidad sobre control

Alternativas

GitHub Flow

Modelo simplificado: solo main + feature branches. Ideal para continuous deployment.

main:     ──●────●────●────●──
              \  /  \  /
feature:       ●     ●

1. Crear rama desde main
2. Hacer commits
3. Abrir PR
4. Review + CI
5. Merge a main
6. Deploy

Trunk-Based Development

Todos trabajan en main (o ramas de vida muy corta). Requiere feature flags y CI robusto.

main:     ──●──●──●──●──●──●──●──

• Commits directos a main o ramas que viven < 1 día
• Feature flags para código incompleto
• Releases por tags o desde main directamente

Comparación

Herramientas

# git-flow CLI (extensión oficial)
brew install git-flow-avh
 
# Inicializar en un repo
git flow init
 
# Usar comandos simplificados
git flow feature start user-auth
git flow feature finish user-auth
git flow release start 1.2.0
git flow release finish 1.2.0
git flow hotfix start 1.2.1
git flow hotfix finish 1.2.1

Anti-patrones

• Develop eternamente divergente de main — si develop y main divergen mucho, los merges son dolorosos
• Feature branches de larga vida — ramas que viven semanas acumulan conflictos
• Saltarse release branches — mergear features directo a main rompe el modelo
• No eliminar ramas terminadas — acumulación de ramas muertas dificulta la navegación

¿Por qué importa?

Entender GitFlow sigue siendo relevante porque muchos equipos lo usan y porque sus limitaciones enseñan por qué la industria migró hacia modelos más simples. Saber cuándo GitFlow es apropiado — y cuándo no — es una decisión arquitectónica que afecta la velocidad de entrega de todo el equipo.

Referencias

• A Successful Git Branching Model — Vincent Driessen, 2010. El post original que definió GitFlow.
• Note of Reflection (2020) — Vincent Driessen, 2020. El propio autor reconoce que GitFlow no es ideal para continuous delivery.
• GitHub Flow — GitHub, 2024. Documentación oficial del modelo simplificado.
• Trunk-Based Development — Paul Hammant, 2024. Referencia completa del modelo trunk-based.