Estrategia de ramas de Git: GitFlow vs. Desarrollo basado en el tronco principal

Al finalizar este tema

Podrás explicar las diferencias entre GitFlow y el desarrollo basado en el tronco principal, y elegir la estrategia adecuada para tu proyecto.

Lo que ocurre cuando hay 5 desarrolladores

Cuando trabajas solo, una sola rama main es suficiente. Pero cuando 5 personas trabajan simultáneamente en la misma base de código, surgen problemas.

A está creando la función de inicio de sesión, mientras que B modifica el mismo archivo y lo sube. C corrigió un error ayer, pero su código entra en conflicto con el de A. D está preparando el lanzamiento, pero E ha enviado código experimental a main.

Es como soltar coches en una carretera sin normas de tráfico. Es necesario crear carriles.

Estrategia 1: Git Flow: 5 carriles

Git Flow divide las ramas en cinco tipos:

main ─────────────────────────────────── (versión estable lanzada)
  │
  └── develop ────────────────────────── (integración en desarrollo de la próxima versión)
        │       │       │
        └── feature/login  (función de inicio de sesión)
        └── feature/search (función de búsqueda)
        │
        └── release/1.2 ─────────────── (QA antes del lanzamiento)
  │
  └── hotfix/urgent-bug ─────────────── (corrección urgente de errores)

main — Actualmente, este es el código que se ofrece a los usuarios. Nadie realiza cambios directamente en esta rama.

develop — Aquí se desarrolla la siguiente versión. Los desarrolladores integran sus cambios una vez que completan las funciones.

feature/ — Se crea una rama para cada función: feature/login, feature/search, etc. Una vez completadas, se integran en la rama develop.

release/ — Esta rama se prepara para las pruebas de control de calidad justo antes del lanzamiento. Aquí se realizan pruebas y se corrigen errores; una vez completado, se integra en la rama main.

hotfix/ — Se utiliza para correcciones urgentes de errores en el código ya publicado. Se crea una rama directamente desde main para corregir el problema y luego se integra tanto en main como en develop.

La ventaja es que el código es más estable. El código experimental nunca llega a los usuarios.

Estrategia 2: Desarrollo basado en un tronco principal — Un único canal, rápido

El desarrollo basado en un tronco principal funciona de manera opuesta. Se utiliza una única rama principal (tronco); cuando se necesita una función o corrección de errores, se crea una rama corta y se integra rápidamente.

main ─── * ─── * ─── * ─── * ─── * ─── (despliegue continuo)
          ↑     ↑     ↑
        ramas cortas (fusionadas en 1-2 días)

Las ramas no deben permanecer activas por mucho tiempo. Deben fusionarse en un plazo de uno o dos días. En su lugar, es imprescindible contar con pruebas automatizadas. Solo el código que supere las pruebas se fusionará en main y, una vez fusionado, se desplegará inmediatamente.

Servicios a gran escala como los de Google y Facebook utilizan este enfoque. Despliegan varias veces al día.

¿Cuál elegir?

No hay una respuesta correcta. Lo importante es que todo el equipo siga las mismas reglas y pueda justificar por qué se eligió esta estrategia. "Porque otros lo hacen" no es un fundamento válido.

En la práctica, a menudo se basa en Git Flow pero se omite la rama de lanzamiento o se adapta según la situación.

Lo único cierto es que los equipos que realizan push directo a main sin una estrategia terminarán repitiendo constantemente: "¿por qué funcionaba ayer esta función?". La estrategia de ramas no sirve para prevenir conflictos de código, sino para mantener la confianza del equipo.

Convenciones para nombrar ramas

Independientemente de la estrategia utilizada, los nombres de las ramas suelen seguir estas reglas:

feature/login          — Nueva funcionalidad
fix/cart-total-bug     — Corrección de errores
hotfix/payment-crash   — Corrección urgente
refactor/auth-cleanup  — Refactorización

El segmento anterior a la barra (/) indica el tipo, y el posterior, la función. Al revisar la lista de ramas, el equipo debe poder identificar rápidamente qué está haciendo cada miembro (por ejemplo, "está implementando la función de inicio de sesión").

Esencial

Git Flow se centra en la estabilidad: filtra el código paso a paso mediante cinco ramas. Trunk-based se centra en la velocidad: integra rápidamente en la rama principal, garantizando la calidad con pruebas automatizadas. Al elegir una estrategia, considere primero la "frecuencia de despliegue" y el "nivel de automatización de las pruebas".