El flujo de ramas que elijas define qué tan fácil es trabajar en equipo, revisar código y desplegar sin miedo. Esta guía cubre el modelo clásico de ramas, buenas prácticas de Git y la automatización con GitHub Actions para pruebas y producción.

1. Elige un modelo de ramas

El más común para equipos pequeños y medianos es el modelo con rama de integración:

  • main — siempre desplegable, contiene lo que está en producción.
  • develop — integración de características en pruebas; se promueve a main.
  • feature/* — una característica o bug por rama, desde develop.
  • hotfix/* — correcciones urgentes, desde main, para desplegar rápido.
  • release/* — preparación de la entrega: solo retoques y versionado.

Alternativa moderna: trunk-based — todos integran en main con ramas cortas de pocas horas y feature flags. Funciona muy bien con despliegue continuo.

2. Convención de nombres

feature/EB-123-login-social
bugfix/EB-240-fix-timezone
hotfix/crash-al-publicar-factura
chore/dep-renovate-dependencias

Incluir el número de ticket (jira/linear/github issues) permite trazar automáticamente código ↔ trabajo.

3. Commits atómicos con Conventional Commits

Un commit = un cambio lógico, con mensaje descriptivo:

feat(auth): agrega validación de token en login
fix(api): corrige respuesta 422 en registro
docs(readme): actualiza instrucciones de instalación

Los prefijos (feat, fix, docs, refactor, test, chore) permiten generar changelogs y versionados semánticos automáticos (semantic-release).

4. Pull Requests y revisión

Cada feature termina en un PR pequeño (menos de 400 líneas es buen indicador). El PR debe incluir: descripción del cambio, cómo se probó, capturas si hay UI y los tests. La revisión busca bugs reales, no solo estilo; los bots de lint y tests corren en CI antes de pedir revisión humana.

5. Protege las ramas

En GitHub: Settings → Branches → Branch protection rules. Configura para main y develop:

  • Require pull request reviews (1-2 revisores).
  • Require status checks (tests, lint, build) pasando antes del merge.
  • Dismiss stale reviews cuando el código cambia.
  • No permitir push directo (solo PRs).
  • Require signed commits si tu equipo lo aplica.

6. Entornos: pruebas y producción

Usa GitHub Environments para segmentar despliegues: un entorno staging (con aprobación opcional) y uno production con reglas de protección (solo desde main, con aprobación). Los secretos de cada entorno viven separados.

7. CI/CD con GitHub Actions

Un flujo clásico con tres stages:

# .github/workflows/ci.yml
on:
  pull_request:
    branches: [main, develop]
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

Y un workflow deploy.yml disparado al hacer merge/push en main que construye, publica la imagen o el bundle y despliega en los entornos configurados.

8. Tags y releases

Los tags marcan versiones inmutables: git tag v1.2.0. Publica releases con nota de cambios y adjunta los artefactos (AAB, bundles). Si algo sale mal, hacer rollback es volver al despliegue de un tag anterior, no a adivinar commits.

9. Checklist final

  • Main siempre desplegable y protegida.
  • Ramas cortas, commits convencionales, PRs pequeños.
  • CI en cada PR; deploy automático desde main.
  • Entornos separados para staging y producción.
  • Tags por release y rollback documentado.