Comparativa de estrategias de branching
Tabla comparativa y árbol de decisión para elegir entre Trunk-Based, GitHub Flow, GitFlow y GitLab Flow.
#Resumen
| Eje | Trunk-Based | GitHub Flow | GitLab Flow | GitFlow |
|---|---|---|---|---|
| Ramas permanentes | 1 (main) |
1 (main) |
main + ambientes/releases |
2 (main, develop) |
| Vida de una rama de trabajo | Horas | Horas a pocos días | Pocos días | Días a semanas |
| Entrega | Continua | Continua | Continua con aprobaciones | Por release planificado |
| Versiones en paralelo | Difícil | No | Sí (ramas de release) | Sí |
| Exige CI maduro | Sí, mucho | Sí | Sí | Menos |
| Complejidad | Baja | Baja | Media | Alta |
| Costo de merge | Mínimo | Bajo | Medio | Alto |
| Mejor para | SaaS, equipos con buen CI | SaaS, equipos chicos/medianos | Ambientes con aprobación | Desktop, mobile, librerías |
#Árbol de decisión
CSHARP
¿Contribuyentes externos sin permiso de escritura? → Forking Workflow
¿Mantenés varias versiones soportadas a la vez? → Ramas de release (GitFlow o GitLab Flow)
¿Necesitás aprobaciones por ambiente? → GitLab Flow
¿Desplegás continuamente y tenés CI sólido? → Trunk-Based
¿Equipo chico, deploy continuo, querés simpleza? → GitHub Flow#Preguntas clave antes de decidir
| Pregunta | Si la respuesta es… | Tendé a |
|---|---|---|
| ¿Cada cuánto desplegás? | Varias veces al día | Trunk-Based / GitHub Flow |
| ¿Cómo llega el software al usuario? | Instalación o app store | GitFlow / ramas de release |
| ¿Cuánto confiás en tus tests? | Poco | Ramas algo más largas, mejorá los tests primero |
| ¿Tamaño del equipo? | Muy grande | Trunk-Based con feature flags |
| ¿Hay gate de QA manual o compliance? | Sí | GitLab Flow |
| ¿Dominás feature flags? | No | GitHub Flow antes que Trunk-Based puro |
Regla: empezá con GitHub Flow y acortá las ramas hasta llegar a Trunk-Based a medida que mejora tu CI. Usá GitFlow solo si tu producto realmente tiene versiones.
#comparison #git