Estrategias de Branching en Git

Introducción

Una estrategia de branching define cómo tu equipo usa ramas de Git para desarrollar, integrar y releasear código. La estrategia correcta depende del tamaño del equipo, la frecuencia de releases y la madurez de CI/CD. Esta guía compara los tres enfoques más comunes.

Trunk-Based Development

En trunk-based development, los desarrolladores commitean directamente a una única rama principal (el “trunk”) usando ramas de cambio de corta duración o commits directos con feature flags.

Flujo de Trabajo

# Traer el último main
git pull origin main

# Crear una rama de cambio de corta duración (horas a un día)
git checkout -b feature/login-button

# Hacer cambios, commitear frecuentemente
git commit -m "feat: add login button"

# Abrir un PR, ser revisado, mergear rápidamente
git push origin feature/login-button
# PR mergeado via squash o rebase

Capacidades

• Duración de rama: Horas a 1-2 días máximo
• Rama principal: Siempre desplegable
• Feature flags: Cambios incompletos se ocultan detrás de toggles
• CI/CD: Ciclos de feedback rápidos; la rama principal se despliega automáticamente

Pros y Contras

Pros	Contras
Mínimos conflictos de merge	Requiere CI/CD maduro
Feedback rápido	Requiere feature flags
Modelo mental simple	Menos adecuado para cambios de larga duración
Ideal para continuous delivery	Requiere disciplina del equipo

Mejor Para

• Equipos que practican continuous delivery
• Microservicios con desplegabilidad independiente
• Organizaciones con testing automatizado fuerte

GitFlow

GitFlow es un modelo de branching estricto con ramas dedicadas para features, releases y hotfixes.

Estructura de Ramas

main        ───●────────────────────●─────
                ↑                    ↑
release/1.0  ───┘──●──●──┘
                    ↑
develop    ───●────●────●────●────●────●───
              ↑    ↑    ↑    ↑
feature/a  ───┘────┘
feature/b  ────────────┘────┘

Flujo de Trabajo

# Iniciar una feature desde develop
git checkout develop
git checkout -b feature/user-profile

# Terminar feature, mergear a develop
git checkout develop
git merge --no-ff feature/user-profile

# Iniciar un release
git checkout -b release/1.2.0 develop
# Bump de versión, fix de últimos bugs
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0

# Hotfix desde main
git checkout -b hotfix/1.2.1 main
# Fix, mergear a main y develop
git checkout main && git merge hotfix/1.2.1
git checkout develop && git merge hotfix/1.2.1

Capacidades

• Rama main: Solo código de producción; releases etiquetados
• Rama develop: Rama de integración para cambios
• Ramas de cambio: Creadas desde develop
• Ramas de release: Preparan y estabilizan releases
• Ramas de hotfix: Fixes de emergencia desde main

Pros y Contras

Pros	Contras
Separación clara de responsabilidades	Complejo; curva de aprendizaje pronunciada
Soporta releases programados	Ramas de larga duración = infierno de merge
Desarrollo paralelo de cambios	Feedback de integración más lento
Aislamiento de hotfixes	Excesivo para equipos pequeños

Mejor Para

• Equipos con releases programados (semanal/mensual)
• Aplicaciones monolíticas que requieren despliegues escalonados
• Organizaciones con procesos formales de QA/UAT

GitHub Flow

GitHub Flow es una variante ligera de trunk-based development optimizada para el workflow de pull requests de GitHub.

Flujo de Trabajo

# Crear una rama de cambio desde main
git checkout -b feature/add-search

# Push y abrir un PR
git push -u origin feature/add-search

# CI ejecuta tests automáticos en el PR
# La revisión de código ocurre en el PR
# Squash and merge cuando está aprobado

# Eliminar rama después del merge
git push origin --delete feature/add-search

Capacidades

• Rama main única: Siempre desplegable
• Ramas de cambio: Creadas desde main, mergeadas via PR
• PR como unidad de trabajo: Revisión, CI, discusión en un solo lugar
• Deploy al merge: La rama main se despliega automáticamente

Pros y Contras

Pros	Contras
Simple e intuitivo	La rama main debe ser siempre desplegable
Ideal para equipos centrados en GitHub	Sin staging de releases integrado
Ciclo de revisión de PR rápido	Menos estructurado que GitFlow
Perfecto para integración con CI/CD	Requiere buena cobertura de tests

Mejor Para

• Productos SaaS con deployment continuo
• Equipos pequeños a medianos usando GitHub
• Proyectos donde cada merge debería ser releaseable

Resumen Comparativo

Aspecto	Trunk-Based	GitFlow	GitHub Flow
Complejidad	Baja	Alta	Baja
Modelo de release	Continuo	Programado	Continuo
Duración de rama	Horas	Días/semanas	Horas-días
Tamaño de equipo	Cualquiera (con disciplina)	Equipos grandes	Pequeño-mediano
Requerimiento CI/CD	Pipeline maduro	Opcional	Requerido
Conflictos de merge	Raros	Comunes	Raros
Rollback	Feature flags	Revertir commits	Revertir commits

Lo que funciona

• Mantén las ramas de corta duración — cuanto más vive una rama, más difícil es el merge
• Usa feature flags para cambios incompletos en main/trunk
• Requiere revisiones de PR antes de mergear a main
• Ejecuta el test suite completo en cada PR; bloquea el merge si falla. Consulta CI/CD.
• Squash o rebase para mantener un historial lineal (preferencia del equipo)
• Etiqueta releases en main para trazabilidad
• Protege las ramas main/develop con reglas de branch protection

Errores Comunes

• Permitir ramas de cambio de larga duración que divergen considerablemente
• No eliminar ramas mergeadas, desordenando el repositorio
• Usar GitFlow para un producto SaaS que se despliega varias veces al día. Consulta estrategias de deployment.
• Mergear sin revisión o checks de CI
• No etiquetar releases, haciendo difíciles los rollbacks

Preguntas Frecuentes

P: ¿Puedo mezclar GitFlow y GitHub Flow? R: Sí. Algunos equipos usan GitHub Flow para el desarrollo diario y ramas de release estilo GitFlow solo para releases de versión mayor.

P: ¿Cómo manejo hotfixes en GitHub Flow? R: Crea una rama de hotfix desde main, fixea, PR, mergea, y despliega inmediatamente. La clave es que main es siempre releaseable.

P: ¿Es trunk-based development lo mismo que continuous deployment? R: No exactamente, pero van de la mano. Trunk-based development es un prerequisito para continuous deployment, pero aún necesitas tests automatizados, feature flags y monitoreo.

¿Cómo empiezo con esto en un proyecto existente?

Empieza con una parte pequeña y aislada de tu codebase. Aplica los conceptos de esta guía a un módulo o servicio. Mide el impacto, luego expande a otras áreas.

¿Qué herramientas necesito?

Las herramientas mencionadas throughout esta guía se listan en cada sección. La mayoría son open-source y ampliamente adoptadas. Consulta los recursos relacionados para instrucciones de setup.

¿Cómo mido el éxito después de implementar esto?

Define métricas claras antes de empezar: benchmarks de rendimiento, tasas de error o indicadores de mantenibilidad. Compara antes y después. Itera basándote en datos, no en suposiciones.

Temas Avanzados

Escenario: Trunk-Based Development para 20 Equipos

Sistema: Monorepo, 20 equipos, 200 servicios
Estrategia: Trunk-based development con feature flags

Flujo diario:
  1. Developer crea rama feature desde main
     git checkout -b feature/payment-v2
  2. Desarrolla localmente con tests
  3. Push diario (keep branches short-lived, < 3 dias)
  4. Abre PR cuando tests pasan
  5. Review: 1 approver + CI verde
  6. Squash merge a main
  7. Deploy automatico a staging desde main
  8. Canary a produccion via feature flag

Feature flags (LaunchDarkly / Unleash):
  // Desplegar codigo inactivo a produccion
  if (featureFlag.isEnabled("payment-v2", user)) {
    return processPaymentV2(payment);
  } else {
    return processPaymentV1(payment);
  }

  // Activar gradualmente:
  // 1% -> 5% -> 25% -> 50% -> 100%
  // Rollback instantaneo: flag off

Reglas de branching:
  | Regla | Razon |
  |-------|-------|
  | Branches < 3 dias | Reduce merge conflicts |
  | Max 400 lineas por PR | Revisiones de calidad |
  | Squash merge | Historial lineal y limpio |
  | CI obligatorio | No mergear codigo rojo |
  | 1 approver minimo | Revision por pares |
  | Feature flags para risks | Decouple deploy de release |
  | No branches release | Deploy desde main |

Comparacion de estrategias:
  | Estrategia | Equipos | Frecuencia deploy | Complejidad |
  |------------|---------|-------------------|-------------|
  | GitFlow | 1-5 | Semanal | Alta |
  | GitHub Flow | 5-20 | Diario | Media |
  | Trunk-based | 20+ | Multiples al dia | Baja |
  | Release Flow | 10-50 | Semanal + hotfix | Media |

Lecciones:
  - Trunk-based + feature flags es el estandar moderno
  - Branches cortas reducen conflictos y bugs
  - Feature flags desacoplan deploy de release
  - Squash merge mantiene historial limpio
  - CI verde obligatorio antes de merge

Como manejo hotfixes en trunk-based?

Crea una rama desde el ultimo tag de release. Aplica el fix. Abre PR directo a main. Una vez mergeado, cherry-pick al tag de release y crea nuevo tag. Si usas feature flags, simplemente activa el flag para el fix. La mayoria de los hotfixes no necesitan branch de release si deployas desde main continuamente.