Estrategias de Branching

Una estrategia de branching define las reglas del equipo para crear, nombrar e integrar ramas. Sin estrategia, cada desarrollador sigue su propio criterio y el historial se vuelve incomprensible. Las más populares son GitFlow (para software con releases programados), GitHub Flow (para despliegue continuo) y Trunk-based Development (para equipos muy ágiles).

GitHub Flow es la más recomendada para equipos modernos: main siempre está deployable, cada nueva función o fix va en una rama con nombre descriptivo, se abre un PR para revisión, se despliega a producción desde la rama antes del merge, y se integra a main. Simple, efectiva y compatible con CI/CD.

# --- GITFLOW ---
# Ramas permanentes: main (producción) y develop (integración)
# Ramas temporales: feature/*, release/*, hotfix/*

git switch develop
git switch -c feature/nueva-funcionalidad
# ... trabajo ...
git switch develop
git merge feature/nueva-funcionalidad

# Para release:
git switch -c release/v2.0.0 develop
# Solo bug fixes en esta rama
git switch main && git merge release/v2.0.0
git tag v2.0.0
git switch develop && git merge release/v2.0.0

# Hotfix (arreglo urgente en producción):
git switch -c hotfix/fix-critico main
# ... fix ...
git switch main && git merge hotfix/fix-critico
git switch develop && git merge hotfix/fix-critico

# --- GITHUB FLOW (más simple) ---
# Solo main + feature branches + PRs
git switch -c feature/login
# ... trabajo ...
# Abrir PR hacia main -> CI -> Code Review -> Merge -> Deploy

# --- TRUNK-BASED DEVELOPMENT ---
# Todos trabajan directo en main (o ramas de vida muy corta)
# Requiere: feature flags, CI muy rápido, alta cobertura de tests
# Short-lived branches: máximo 1-2 días de vida