Estrategias de branching

Trunk-Based Development, GitHub Flow, GitFlow, GitLab Flow y Forking. Cómo organizar ramas, releases y hotfixes según tu equipo.

Una estrategia de branching define cómo el equipo usa las ramas de Git: dónde se integra el trabajo, cuánto vive una rama, cómo se arma un release y cómo se corrige un bug en producción.

#El problema

Sin acuerdo, cada persona usa Git a su manera. Aparecen ramas que viven semanas, merges gigantes con conflictos, main roto, releases que nadie sabe qué contienen y hotfixes que se pierden en el próximo deploy. El costo de integrar crece con el tiempo que pasa sin integrar.

#La solución

Elegir una estrategia explícita y escribirla. La variable que más importa no es el nombre del flujo sino cuánto tarda el código en llegar a la rama principal. Cuanto menos vivan las ramas, menos duelen los merges y más rápido llegás a producción.

#Cómo elegir: preguntas clave

  1. ¿Cómo se entrega el software? Deploy continuo (web, SaaS) → Trunk-Based o GitHub Flow. Versiones instaladas por el cliente (desktop, mobile, librerías, on-premise) → GitFlow o ramas de release.
  2. ¿Cuántas versiones tenés que mantener a la vez? Una sola → flujos simples. Varias → ramas de release.
  3. ¿Qué tan buena es tu automatización? Sin CI ni tests confiables, ramas cortas no son seguras. Con CI sólido, Trunk-Based rinde mucho.
  4. ¿Podés esconder trabajo incompleto? Con Feature Flags podés integrar a diario código que todavía no se muestra.
  5. ¿Quiénes contribuyen? Equipo de confianza → ramas directas en el repo. Contribuyentes externos → Forking.
  6. ¿Hay aprobaciones por ambiente (compliance)? → GitLab Flow con ramas de ambiente.

La estrategia es independiente del estilo de despliegue, pero se condicionan: un Modulith o un monolito con un solo pipeline casi siempre se lleva bien con Trunk-Based; versionar contratos entre microservicios agrega complejidad de releases.

#En este capítulo

  • Trunk-Based Development — todos integran en main al menos una vez al día.
  • GitHub Flow — ramas cortas con Pull Request y deploy desde main.
  • GitFlow — develop, release y hotfix para software versionado.
  • GitLab Flow — main más ramas de ambiente o de release.
  • Forking Workflow — cada contribuyente trabaja en su propio fork.
  • Comparativa — tabla y árbol de decisión.
  • Trunk-Based Development — Todo el equipo integra en una única rama (trunk/main) con ramas de vida muy corta y feature flags.
  • GitHub Flow — main siempre desplegable, ramas cortas por cambio, Pull Request y deploy tras el merge.
  • GitFlow — main, develop, feature, release y hotfix. Pensado para software versionado con releases planificados.
  • GitLab Flow — GitHub Flow más ramas de ambiente (staging, production) o de release, con regla de "upstream first".
  • Forking Workflow — Cada contribuyente trabaja en su propio fork y propone cambios por Pull Request al repositorio principal.
  • Comparativa de estrategias de branching — Tabla comparativa y árbol de decisión para elegir entre Trunk-Based, GitHub Flow, GitFlow y GitLab Flow.