Estrategias de Branching en Git

Introducción

Una estrategia de branching define cómo tu equipo usa ramas de Git para desarrollar, integrar y releasear código. La estrategia correcta depende del tamaño del equipo, la frecuencia de releases y la madurez de CI/CD. Esta guía compara los tres enfoques más comunes.

Trunk-Based Development

En trunk-based development, los desarrolladores commitean directamente a una única rama principal (el “trunk”) usando ramas de feature de corta duración o commits directos con feature flags.

Flujo de Trabajo

# Traer el último main
git pull origin main

# Crear una rama de feature de corta duración (horas a un día)
git checkout -b feature/login-button

# Hacer cambios, commitear frecuentemente
git commit -m "feat: add login button"

# Abrir un PR, ser revisado, mergear rápidamente
git push origin feature/login-button
# PR mergeado via squash o rebase

Características

Duración de rama: Horas a 1-2 días máximo
Rama principal: Siempre desplegable
Feature flags: Funcionalidades incompletas se ocultan detrás de toggles
CI/CD: Ciclos de feedback rápidos; la rama principal se despliega automáticamente

Pros y Contras

Pros	Contras
Mínimos conflictos de merge	Requiere CI/CD maduro
Feedback rápido	Requiere feature flags
Modelo mental simple	Menos adecuado para features de larga duración
Ideal para continuous delivery	Requiere disciplina del equipo

Mejor Para

Equipos que practican continuous delivery
Microservicios con desplegabilidad independiente
Organizaciones con testing automatizado fuerte

GitFlow

GitFlow es un modelo de branching estricto con ramas dedicadas para features, releases y hotfixes.

Estructura de Ramas

main        ───●────────────────────●─────
                ↑                    ↑
release/1.0  ───┘──●──●──┘
                    ↑
develop    ───●────●────●────●────●────●───
              ↑    ↑    ↑    ↑
feature/a  ───┘────┘
feature/b  ────────────┘────┘

Flujo de Trabajo

# Iniciar una feature desde develop
git checkout develop
git checkout -b feature/user-profile

# Terminar feature, mergear a develop
git checkout develop
git merge --no-ff feature/user-profile

# Iniciar un release
git checkout -b release/1.2.0 develop
# Bump de versión, fix de últimos bugs
git checkout main
git merge --no-ff release/1.2.0
git tag -a v1.2.0

# Hotfix desde main
git checkout -b hotfix/1.2.1 main
# Fix, mergear a main y develop
git checkout main && git merge hotfix/1.2.1
git checkout develop && git merge hotfix/1.2.1

Características

Rama main: Solo código de producción; releases etiquetados
Rama develop: Rama de integración para features
Ramas de feature: Creadas desde develop
Ramas de release: Preparan y estabilizan releases
Ramas de hotfix: Fixes de emergencia desde main

Pros y Contras

Pros	Contras
Separación clara de responsabilidades	Complejo; curva de aprendizaje pronunciada
Soporta releases programados	Ramas de larga duración = infierno de merge
Desarrollo paralelo de features	Feedback de integración más lento
Aislamiento de hotfixes	Excesivo para equipos pequeños

Mejor Para

Equipos con releases programados (semanal/mensual)
Aplicaciones monolíticas que requieren despliegues escalonados
Organizaciones con procesos formales de QA/UAT

GitHub Flow

GitHub Flow es una variante ligera de trunk-based development optimizada para el workflow de pull requests de GitHub.

Flujo de Trabajo

# Crear una rama de feature desde main
git checkout -b feature/add-search

# Push y abrir un PR
git push -u origin feature/add-search

# CI ejecuta tests automáticos en el PR
# La revisión de código ocurre en el PR
# Squash and merge cuando está aprobado

# Eliminar rama después del merge
git push origin --delete feature/add-search

Características

Rama main única: Siempre desplegable
Ramas de feature: Creadas desde main, mergeadas via PR
PR como unidad de trabajo: Revisión, CI, discusión en un solo lugar
Deploy al merge: La rama main se despliega automáticamente

Pros y Contras

Pros	Contras
Simple e intuitivo	La rama main debe ser siempre desplegable
Ideal para equipos centrados en GitHub	Sin staging de releases integrado
Ciclo de revisión de PR rápido	Menos estructurado que GitFlow
Perfecto para integración con CI/CD	Requiere buena cobertura de tests

Mejor Para

Productos SaaS con deployment continuo
Equipos pequeños a medianos usando GitHub
Proyectos donde cada merge debería ser releaseable

Resumen Comparativo

Aspecto	Trunk-Based	GitFlow	GitHub Flow
Complejidad	Baja	Alta	Baja
Modelo de release	Continuo	Programado	Continuo
Duración de rama	Horas	Días/semanas	Horas-días
Tamaño de equipo	Cualquiera (con disciplina)	Equipos grandes	Pequeño-mediano
Requerimiento CI/CD	Pipeline maduro	Opcional	Requerido
Conflictos de merge	Raros	Comunes	Raros
Rollback	Feature flags	Revertir commits	Revertir commits

Buenas Prácticas

Mantén las ramas de corta duración — cuanto más vive una rama, más difícil es el merge
Usa feature flags para funcionalidades incompletas en main/trunk
Requiere revisiones de PR antes de mergear a main
Ejecuta el test suite completo en cada PR; bloquea el merge si falla
Squash o rebase para mantener un historial lineal (preferencia del equipo)
Etiqueta releases en main para trazabilidad
Protege las ramas main/develop con reglas de branch protection

Errores Comunes

Permitir ramas de feature de larga duración que divergen significativamente
No eliminar ramas mergeadas, desordenando el repositorio
Usar GitFlow para un producto SaaS que se despliega varias veces al día
Mergear sin revisión o checks de CI
No etiquetar releases, haciendo difíciles los rollbacks

Preguntas Frecuentes

P: ¿Puedo mezclar GitFlow y GitHub Flow? R: Sí. Algunos equipos usan GitHub Flow para el desarrollo diario y ramas de release estilo GitFlow solo para releases de versión mayor.

P: ¿Cómo manejo hotfixes en GitHub Flow? R: Crea una rama de hotfix desde main, fixea, PR, mergea, y despliega inmediatamente. La clave es que main es siempre releaseable.

P: ¿Es trunk-based development lo mismo que continuous deployment? R: No exactamente, pero van de la mano. Trunk-based development es un prerequisito para continuous deployment, pero aún necesitas tests automatizados, feature flags y monitoreo.