GitHub Flow

GitHub Flow es un modelo de branching simplificado creado por GitHub en 2011 como alternativa ligera a GitFlow. Su premisa: main siempre está deployable, y cada cambio pasa por un Pull Request.

¿Por qué existe?

GitFlow fue diseñado para software con releases programados. Pero para equipos que hacen deploy múltiples veces al día, sus múltiples ramas (develop, release/*, hotfix/*) agregan fricción sin beneficio.

GitHub Flow reduce todo a lo esencial:

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

Las 6 reglas

1. main siempre es deployable — cualquier commit en main puede ir a producción
2. Crear rama descriptiva desde main — feature/add-login, fix/header-overflow
3. Commits frecuentes a la rama — push temprano y seguido para backup y visibilidad
4. Abrir PR cuando necesites feedback — no esperar a terminar; PRs draft existen para esto
5. Merge solo después de review — al menos una aprobación antes de mergear
6. Deploy inmediatamente después de merge — o incluso antes (deploy desde la rama)

Flujo completo

# 1. Crear rama desde main actualizado
git checkout main
git pull origin main
git checkout -b feature/user-notifications
 
# 2. Trabajar y hacer commits
git add .
git commit -m "feat: add notification preferences UI"
git push -u origin feature/user-notifications
 
# 3. Abrir PR en GitHub
gh pr create --title "feat: user notifications" --body "Adds notification preferences"
 
# 4. Iterar basado en review
git commit -m "fix: address review comments"
git push
 
# 5. Merge después de aprobación (squash recomendado)
gh pr merge --squash
 
# 6. Deploy automático (CI/CD se encarga)
# main → staging → producción

¿Cuándo usarlo?

Ideal para:

• Aplicaciones web con un solo entorno de producción
• Equipos que practican continuous deployment
• Startups y equipos pequeños-medianos
• Proyectos donde la velocidad importa más que el control ceremonial
• SaaS, APIs, microservicios

Considerar alternativas cuando:

• Necesitas mantener múltiples versiones en producción (v1, v2, v3)
• Releases requieren QA formal de varios días
• Software empaquetado con ciclos de release largos
• Regulaciones requieren trazabilidad estricta de releases

GitHub Flow vs GitFlow

Patrones complementarios

Feature flags

Permiten mergear código incompleto a main sin exponerlo a usuarios:

if (featureFlags.isEnabled('new-checkout')) {
  return <NewCheckout />;
}
return <LegacyCheckout />;

Beneficios:

• PRs más pequeños y frecuentes
• Testing en producción con usuarios seleccionados
• Rollback instantáneo sin deploy

Branch deploy

Deployar la rama antes de mergear para validar en un entorno real:

# .github/workflows/branch-deploy.yml
on:
  pull_request:
    types: [labeled]
 
jobs:
  deploy-preview:
    if: github.event.label.name == 'deploy-preview'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy-to-preview.sh

Conventional commits

Estructura los mensajes para generar changelogs automáticos:

feat: add user notifications
fix: resolve header overflow on mobile
docs: update API documentation
chore: upgrade dependencies

CI/CD típico

name: CI/CD
 
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
      - run: npm run lint
 
  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build
      - run: ./deploy.sh

Anti-patrones

• PRs gigantes — difíciles de revisar, alto riesgo. Dividir en PRs pequeños.
• Main roto — si main no es deployable, el modelo colapsa. CI obligatorio.
• Ramas de larga vida — más de 2-3 días acumula conflictos. Mergear frecuentemente.
• Saltarse el review — merge directo a main sin PR elimina la red de seguridad.
• Deploy manual — si el deploy no es automático, se acumula trabajo y aumenta el riesgo.

¿Por qué importa?

GitHub Flow es el modelo de branching más adoptado en equipos que practican continuous delivery. Su simplicidad — una sola rama principal, feature branches cortas, deploy tras merge — elimina la ceremonia de modelos más complejos como GitFlow y reduce el tiempo entre escribir código y ponerlo en producción.

Referencias

• GitHub Flow — GitHub, 2024. Documentación oficial.
• Understanding the GitHub Flow — GitHub Guides, 2024. Guía visual del flujo.
• Scott Chacon on GitHub Flow — Scott Chacon, 2011. Post original explicando por qué GitHub abandonó GitFlow.
• Ship Small, Ship Fast — Dan McKinley, 2017. Por qué PRs pequeños reducen riesgo.
• Comparing Workflows — Atlassian, 2024. Comparativa entre GitFlow, GitHub Flow y trunk-based development.