Estrategias avanzadas de branching

Estrategias de branching

La estrategia correcta depende del tamaño del equipo, la frecuencia de releases y el modelo de despliegue.

Git Flow

Ideal para proyectos con releases programados y múltiples versiones en producción:

# Initialize Git Flow
git flow init

# Feature development
git flow feature start user-auth
# Work on feature...
git flow feature finish user-auth

# Release preparation
git flow release start 1.0.0
# Prepare release...
git flow release finish 1.0.0

# Hotfix for production
git flow hotfix start critical-bug
# Fix bug...
git flow hotfix finish critical-bug

Estructura de ramas en Git Flow

main ─────●─────────────●─────────────●──────
          │             │             │
          │   release/1.0.0          hotfix/fix
          │      │                    │
develop ──●──────●───────●────●───────●──────
          │              │    │
    feature/auth    feature/dashboard

GitHub Flow

Modelo más simple para despliegue continuo:

# Create feature branch from main
git checkout main
git pull origin main
git checkout -b feature/new-feature

# Work and commit
git add .
git commit -m "Add new feature"

# Push and create PR
git push -u origin feature/new-feature
gh pr create --title "Add new feature" --body "Description"

# After review and merge, deploy from main
git checkout main
git pull origin main

Trunk-Based Development

Ramas de vida corta que se integran directo a main:

# Create short-lived branch
git checkout main
git pull
git checkout -b short-lived-feature

# Make small, focused changes
git commit -m "Small incremental change"

# Merge same day or next day
git checkout main
git merge short-lived-feature
git push

# Use feature flags for incomplete features
if (featureFlags.newDashboard) {
  // New code path
}

Reglas de protección de ramas

# GitHub CLI to set branch protection
gh api repos/{owner}/{repo}/branches/main/protection -X PUT \
  -f required_pull_request_reviews='{"required_approving_review_count":2}' \
  -f enforce_admins=true \
  -f required_status_checks='{"strict":true,"contexts":["ci/tests"]}'

# View protection rules
gh api repos/{owner}/{repo}/branches/main/protection

Trabajar con ramas de larga duración

# Keep feature branch updated with main
git checkout feature-branch
git fetch origin
git rebase origin/main

# Or merge main into feature
git merge origin/main

# Check if branch is behind main
git rev-list --left-right --count main...feature-branch
# Output: 5    3  (5 commits behind, 3 ahead)

Convenciones de nombres de ramas

# Common patterns
feature/JIRA-123-user-authentication
bugfix/JIRA-456-fix-login-error
hotfix/critical-security-patch
release/v1.2.0
experiment/new-ui-concept

# Enforce with Git hooks
# .git/hooks/pre-commit
#!/bin/bash
branch=$(git branch --show-current)
pattern="^(feature|bugfix|hotfix|release|experiment)/[a-z0-9-]+$"
if ! [[ $branch =~ $pattern ]]; then
  echo "Branch name must match pattern: $pattern"
  exit 1
fi

Limpieza de ramas

# Delete merged local branches
git branch --merged main | grep -v "main" | xargs git branch -d

# Delete remote branches
git push origin --delete feature-branch

# Prune stale remote-tracking branches
git fetch --prune

# Find stale branches (no commits in 30 days)
git for-each-ref --sort=-committerdate refs/heads/ \
  --format='%(committerdate:short) %(refname:short)' | \
  awk '$1 < "'$(date -d '30 days ago' +%Y-%m-%d)'"'

Comparación de ramas

# Compare branches
git diff main..feature-branch

# List commits in feature not in main
git log main..feature-branch --oneline

# List commits in main not in feature
git log feature-branch..main --oneline

# Show commits unique to each branch
git log main...feature-branch --oneline --left-right

Comparación de estrategias

Estrategia	Mejor para	Frecuencia de releases	Complejidad
Git Flow	Software versionado	Programada	Alta
GitHub Flow	Web apps, SaaS	Continua	Baja
Trunk-Based	Equipos de alta velocidad	Continua	Media