Git flow vs trunk-based development: cuál elegir y por qué
- git
- desarrollo
- arquitectura
- workflow
- branching
Impacto de la estrategia de Git en el desarrollo de software
Cada equipo de desarrollo elige una estrategia para gestionar su código fuente con Git. Las dos más comunes son Git Flow y Trunk-Based Development. La diferencia entre ambas no es solo técnica, sino de filosofía de equipo y de cómo se gestiona el ciclo de vida del software.
Elegir mal impacta directamente en la velocidad de despliegue, la frecuencia de los errores en producción y la capacidad del equipo para colaborar sin pisarse.
Cómo funciona Git Flow y cuándo tiene sentido
Git Flow es un modelo de branching robusto que propone un conjunto de ramas de larga duración para manejar el desarrollo de nuevas características, los lanzamientos y las correcciones. Típicamente, involucra ramas main (o master), develop, feature, release y hotfix.
Una nueva funcionalidad se desarrolla en una rama feature, se fusiona a develop, y cuando hay suficientes funcionalidades para una versión, se crea una rama release. Las correcciones urgentes van en ramas hotfix. Este flujo fue popular en equipos que lanzaban versiones grandes cada cierto tiempo.
Funciona bien si:
- Tu equipo trabaja en ciclos de lanzamiento largos, de semanas o meses.
- Necesitas mantener múltiples versiones en producción simultáneamente.
- La estabilidad es crítica y los despliegues son infrecuentes y controlados.
Deja de funcionar cuando:
- Buscas despliegues continuos o muy frecuentes.
- El equipo es pequeño y los “cuellos de botella” por fusiones se vuelven constantes.
- La complejidad de gestionar tantas ramas introduce más errores que los que previene.
Trunk-Based Development: integración continua y despliegues rápidos
El Trunk-Based Development (TBD) es una estrategia de branching donde todos los desarrolladores integran su código en una única rama principal, el trunk (o main), al menos una vez al día. Las ramas de larga duración son inexistentes.
Para gestionar las funcionalidades que no están listas o que necesitan activarse en un momento dado, se usan feature flags. Estas banderas permiten desplegar código inacabado o experimental a producción sin que afecte a los usuarios finales.
Funciona bien si:
- Tu equipo busca la integración y el despliegue continuo (CI/CD).
- Quieres lanzar funcionalidades pequeñas y a menudo.
- La colaboración cercana y la visibilidad constante del código son prioritarias.
Deja de funcionar cuando:
- No tienes una estrategia sólida de feature flags o pruebas automatizadas.
- El equipo no está acostumbrado a la disciplina de integración frecuente.
- Necesitas gestionar ramas de versiones estables para clientes específicos.
Comparativa: Git Flow vs Trunk-Based Development
| Característica | Git Flow | Trunk-Based Development |
|---|---|---|
| Ramas principales | main (estable), develop (integración) | main (integración y estable) |
| Frecuencia de fusión | Semanas/meses, fusiones complejas | Diaria, fusiones pequeñas y frecuentes |
| Despliegues | Infrecuentes, versiones grandes | Frecuentes, pequeñas y continuas |
| Complejidad | Alta gestión de ramas, riesgo de conflictos | Baja gestión de ramas, alto riesgo de rotura |
| Integración Continua | Difícil de implementar de forma nativa | Diseñado para CI/CD |
| Necesidad de tests | Importante en release | Crítico y automatizado en cada push |
Mi experiencia con equipos que adoptan TBD es que la integración es menos dolorosa. La diferencia entre que tu código funcione en local y falle en producción a menudo se reduce a la frecuencia con la que se integra el código.
Ventajas y desventajas de Git Flow y Trunk-Based Development
Con Git Flow se gana estabilidad en lanzamientos grandes, control estricto sobre lo que va a producción y facilidad para mantener múltiples versiones. Con Trunk-Based Development se obtiene velocidad de desarrollo, integración continua, feedback rápido y menos conflictos de fusión complejos.
Git Flow complica las fusiones, ralentiza los ciclos de desarrollo, dificulta la implementación de CI/CD efectivo y aumenta el riesgo de ramas estancadas. Trunk-Based Development exige una suite de tests robusta, disciplina de integración constante y dependencia de feature flags para gestionar funcionalidades incompletas.
En ambos casos, las pruebas automatizadas son necesarias. En TBD, actúan como red de seguridad. En Git Flow, son la garantía antes de un lanzamiento. Además, es necesaria una cultura de equipo que entienda y se comprometa con el flujo elegido. Un flujo de trabajo no es una solución mágica.
Cuando un cliente me llega con problemas de lentitud en sus despliegues o conflictos constantes, el flujo de branching es lo primero que reviso. Para proyectos donde la velocidad es un requisito, el Trunk-Based Development es mi elección. Si trabajas con APIs, saber cómo versionar una API sin romper a los consumidores es un complemento esencial para tu estrategia de desarrollo.
Si estás definiendo la arquitectura de tu aplicación, este artículo sobre cuándo dividir un proyecto en microservicios te dará más contexto. Asegurarte de que tu código funciona bien entre entornos es clave. Puedes profundizar en cómo la caché en aplicaciones web ayuda o estorba según la situación.
Técnico freelance especializado en desarrollo a medida, automatizaciones con IA y gestión técnica para negocios en España. Más sobre mí →
¿Necesitas desarrollo a medida?
Desarrollo funcionalidades específicas, integraciones entre sistemas y herramientas internas. Si se puede programar, probablemente puedo hacerlo.