Estrategias de Branching Git: Gitflow vs Trunk-Based vs GitHub Flow

Branching Git: No Hay Una Única Manera Correcta

Todos los equipos discuten sobre estrategias de branching en algún momento. La verdad es que no existe un mejor enfoque universal — depende del tamaño del equipo, cadencia de releases y modelo de deploy. Aquí están las tres estrategias más populares con trade-offs honestos.

GitHub Flow (Simple)

main ─────●─────●─────●─────●─────●─────
            \         /
             feature ●

Cómo funciona:

Crea branch desde main
Haz commits, push al remoto
Abre un pull request
Recibe code review
Merge a main
main siempre está deployable

git checkout -b feature/add-search
# ... trabaja, commitea, push ...
git push -u origin feature/add-search
# Abre PR en GitHub, recibe review, merge

Pros	Contras
Simplicísimo — una regla de branch	Sin separación entre "lanzado" y "en progreso"
Iteración rápida	Requiere madurez de CI/CD (deploy automático al merge)
Funciona genial para SaaS / web apps	Más difícil para apps móviles con ciclos de release

Mejor para: Equipos pequeños, productos SaaS, deploy continuo.

Gitflow (Complejo)

main     ─────●───────────────●───────
              |               |       
release       |    ●────●     |       
              |   /      \    |       
develop ──●──●──●────●────●──●───●──
           \      /       \      /    
feature     ●───●          ●───●

Cómo funciona:

main — solo releases de producción, taggeado con versiones
develop — branch de integración, siempre tiene las features más recientes
feature/* — branch desde develop, merge de vuelta a develop
release/* — branch desde develop cuando está listo para release, solo bug fixes
hotfix/* — branch desde main para fixes urgentes de producción

Pros	Contras
Clara separación de responsabilidades	Demasiadas branches y ceremonia
Gestión explícita de releases	Conflictos de merge se acumulan en develop
Bueno para software versionado	Lento — features esperan ventanas de release

Mejor para: Software empaquetado, apps móviles con releases en app store, equipos con etapas de QA.

Trunk-Based Development (Rápido)

main ──●──●──●──●──●──●──●──●──●──
        \  /   \  /
         ●      ●
      (branches cortas, < 1 día)

Cómo funciona:

Todos commitean en main (o branches muy cortas mergeadas el mismo día)
Feature flags ocultan trabajo incompleto
CI corre en cada commit
Releases son tags en main, o deploy continuo

# Branch de vida corta (mergeada en horas)
git checkout -b fix/typo-in-header
git commit -am "Fix typo in header component"
git push -u origin fix/typo-in-header
# PR creado, revisado, mergeado el mismo día

# O commitear directo en main (con protección CI)
git commit -am "Add search endpoint behind feature flag"
git push origin main

Pros	Contras
Loop de feedback más rápido	Requiere excelente CI/CD y testing
Sin infierno de merge	Feature flags agregan complejidad
Usado por Google, Meta, etc.	Requiere disciplina del equipo

Mejor para: Equipos experimentados, deploy continuo, microservicios.

Comparación

Factor	GitHub Flow	Gitflow	Trunk-Based
Complejidad	Baja	Alta	Baja
Vida de la branch	Días	Días a semanas	Horas
Conflictos de merge	Ocasionales	Frecuentes	Raros
Modelo de release	Continuo	Agendado	Continuo
Madurez CI/CD necesaria	Media	Baja	Alta
Tamaño del equipo	2-15	5-50+	Cualquiera (con disciplina)

Consejos Prácticos

Mantén branches de vida corta. Cualquier branch abierta más de 3 días es un conflicto de merge esperando suceder.
Elimina branches después del merge. git branch -d feature/done y habilita auto-delete en GitHub.
Protege main. Exige PR reviews y CI pasando antes del merge.
Rebase antes de mergear para mantener historial limpio: git rebase main en tu feature branch.
Usa conventional commits para changelogs automatizados: feat:, fix:, chore:.

Referencia Git: Cheatsheet Git — todos los comandos git comunes, buscables y categorizados.