5 min
Trunk-based o GitFlow: cómo elegir el flujo de ramas
La discusión se plantea como religiosa y casi nunca lo es. Dos preguntas sobre tu producto deciden la respuesta en un minuto.
Cada cierto tiempo un equipo se enzarza en si usar trunk-based o GitFlow como si fuera una cuestión de principios. Casi siempre es una cuestión de dos propiedades del producto.
Pregunta uno: ¿mantienes varias versiones a la vez?
Si vendes software con versiones numeradas y das soporte a la 3.x mientras desarrollas la 4.0, necesitas ramas de larga vida para arreglar la 3.x sin arrastrar lo nuevo. Eso es GitFlow o una variante. Si solo existe «lo que hay en producción ahora mismo», no tienes ese problema.
Pregunta dos: ¿con qué frecuencia despliegas?
Si despliegas varias veces por semana o por día, las ramas de larga vida se convierten en un peaje: cada fusión es grande y arriesgada. Trunk-based —integrar en main a diario, detrás de *feature flags* si algo no está listo— reduce el tamaño del lote y con él el riesgo.
- Una versión soportada + despliegue frecuente → trunk-based.
- Varias versiones soportadas → GitFlow, aunque despliegues a menudo.
- Una versión + despliegue trimestral → cualquiera de los dos sirve; elige el más simple.
La guía completa de flujo de ramas, revisión y publicaciones está en Git y control de versiones en equipo.
- Git
- Procesos
- DevOps
Guías relacionadas
Siguiente paso
Media hora bien invertida
Cuéntanos el problema en una llamada corta. Salimos con una primera orientación de por dónde iría y qué implicaría, sin compromiso y sin presentación comercial.