9. Comparación y conclusión: Git Flow vs Trunk-Based
Dos modelos, dos filosofías
En los módulos anteriores exploraste cada modelo en detalle. Ahora que tenés ambos claros, vale la pena ponerlos frente a frente y entender cuándo conviene cada uno — porque la respuesta no es única: depende del equipo, el tipo de producto y la madurez del proceso de entrega.
Tabla comparativa
| Criterio | Git Flow | Trunk-Based |
|---|---|---|
| Ramas activas | Varias en paralelo: main, develop, feature/*, release/*, hotfix/*. | Solo el trunk (main) y ramas cortas de trabajo que viven horas o pocos días. |
| Frecuencia de integración | Features pueden vivir días o semanas en develop antes de llegar a producción. | Varias integraciones al día; el trunk refleja casi siempre el estado más reciente. |
| Mejor para | Releases versionados (semestral, instalables, contratos), equipos que necesitan congelar versiones. | Despliegue continuo (SaaS, microservicios), equipos con CI/CD maduro que liberan frecuente. |
| Riesgo de divergencia | Alto si las features viven mucho en develop sin integrarse: el merge final puede ser doloroso. | Bajo si el equipo mergea seguido; el conflicto se detecta antes porque las ramas son pequeñas. |
| Hotfixes | Camino explícito: hotfix/* desde main → main + develop. | El parche va al trunk; puede usar feature flags para apagar la funcionalidad afectada de inmediato. |
| Curva de aprendizaje | Media-alta: hay que aprender las reglas de cada tipo de rama y cuándo crearla. | Baja en teoría ("todo va a main"), pero exige disciplina real y herramientas maduras. |
| Coste oculto | Mantenimiento de ramas largas, merges entre release, develop y main, y coordinación de versiones. | Exige tests confiables, revisión ágil y, a menudo, infraestructura de feature flags. Sin eso, main se vuelve frágil. |
¿Y qué es GitHub Flow?
Entre los dos extremos existe un modelo muy popular en equipos medianos: GitHub Flow. Su
idea es simple: main siempre está desplegable, y cualquier cambio nuevo pasa por una rama de
feature corta + Pull Request hacia main. No hay develop permanente ni ciclos de
release formales. Esencialmente es un punto intermedio —
más estructura que TBD puro, mucho más simple que Git Flow clásico — y funciona muy bien para equipos web
que despliegan con frecuencia pero no tienen CI/CD completamente automatizado.
Guía rápida para elegir
Elegí Git Flow si…
- Publicás versiones numeradas con ciclos de lanzamiento formales.
- Necesitás mantener varias versiones activas en paralelo (v2.x y v3.x).
- El equipo tiene roles definidos y procesos de aprobación por versión.
- El cliente o el contrato exige releases etiquetadas y auditables.
Elegí Trunk-Based si…
- Tenés CI/CD maduro y buscás desplegar varias veces al día.
- El producto es SaaS o web con una sola versión en producción.
- El equipo revisa PRs rápido y tiene tests confiables.
- Querés minimizar el riesgo de "merge conflicts gigantes".
Considerá GitHub Flow si…
- Sos un equipo pequeño o mediano con despliegue frecuente.
- No necesitás congelar versiones pero tampoco tenés CI completo.
- Querés más simplicidad que Git Flow sin depender de feature flags.
Conclusión: no hay un ganador universal
Git Flow y Trunk-Based no son rivales — son herramientas diseñadas para contextos distintos. Un equipo que publica firmware embedded con ciclos de seis meses y validación regulatoria tiene necesidades completamente diferentes a una startup de SaaS que despliega cada hora.
Lo que sí es universal: el modelo que elijas debe ser conocido y aplicado de forma consistente por todo el equipo. Un Git Flow aplicado a medias es peor que GitHub Flow bien ejecutado. La mejor estrategia de ramas es la que tu equipo entiende, mantiene y puede explicarle a un desarrollador nuevo en diez minutos.
Con esto cerrás el curso de Git: desde entender qué es un commit hasta los modelos de ramificación que usan los equipos profesionales. El siguiente paso es la práctica: abrí un repo, definí el modelo con tu equipo, y empezá a iterar.
🎓 ¡Curso completo! Dominás el control de versiones con Git: desde git init hasta modelos de
colaboración profesional con Git Flow y Trunk-Based.
Quiz final: Git Flow vs Trunk-Based
Último repaso antes de cerrar el curso: comparación, casos de uso y GitHub Flow.
