El branching estratégico es como la arquitectura vial de tu proyecto: si todos manejan por cualquier calle sin reglas, habrá choques y caos. Así que vamos a ver los modelos más usados y cuándo conviene uno u otro.

🧱 1. Git Flow (el clásico)

Fue propuesto por Vincent Driessen y es ideal para proyectos con:

  • Versiones planificadas.
  • Equipos medianos o grandes.
  • Necesidad de mantenimiento en paralelo a nuevas features.

Branches típicos:

  • main: el código en producción.
  • develop: el código listo para el próximo release (lo que sería staging).
  • feature/xxx: una rama para cada nueva funcionalidad.
  • release/x.y.z: para estabilizar una versión antes de ir a producción.
  • hotfix/x.y.z: parches urgentes sobre producción.

🔧 Ventajas:

  • Estructurado.
  • Permite trabajar en paralelo sin miedo.
  • Buen control para releases formales.

🔥 Desventajas:

  • Mucho “ceremonial”.
  • Puede ser overkill para equipos pequeños o proyectos de deploy continuo.

🚂 2. Trunk-Based Development (tryhard)

Acá todos trabajan sobre una sola rama (main, trunk, o como le digas), con ramas temporales muy cortas (a veces ni siquiera existen).

Usado por empresas que hacen deploys múltiples al día como Google o Facebook.

🔧 Ventajas:

  • Simplifica el flujo.
  • Promueve integración continua real.
  • Menos conflictos por ramas viejas o divergentes.

🔥 Desventajas:

  • Necesita tests automatizados robustos.
  • Puede generar bugs en producción si no se hace bien.

🧪 3. Modelo híbrido (GitHub Flow / Simplified Flow)

Es lo más común en startups y equipos medianos: una mezcla de Git Flow y Trunk-Based.

  • main: producción.
  • dev o staging: entorno de pruebas previo a producción.
  • feature/xxx: ramas de corto ciclo.
  • A veces se usa release/x.y.z, pero no es obligatorio.

🔧 Ventajas:

  • Balance entre control y velocidad.
  • Requiere poca infraestructura para funcionar.

🔥 Desventajas:

  • Si no hay convenciones claras, puede volverse un desastre.

El principio clave de GitHub Flow / Simplified Flow es que la rama main siempre está en un estado deployable, lo que significa que una vez fusionados, los cambios pueden implementarse en producción casi inmediatamente.

Actualmente trabajo en un proyecto mediano que apunta para ser grande entonces en el equipo de desarrollo creemos que lo mejor es utilizar Git Flow, por lo que para despejar aun mas dudas si llegaran a quedar dejo una entrada explicando cual seria el flujo típico de una feature con esta metodología:

Flujo básico de una feature usando Git Flow (con ejemplos vanilla)