Lo que lograrás

Configurarás un workflow de code review que escala de tres a treinta contribuidores: branch protection, CODEOWNERS, plantillas de PR, verificaciones automatizadas, y convenciones para revisores y autores.

Paso 1: elegir un modelo

El modelo dominante en 2026 es GitHub Flow:

• Único branch main de larga vida.
• Branches feature desde main.
• PR para review y CI.
• Merge tras aprobación y verificaciones verdes.

Paso 2: branch protection

• Requerir un PR antes de mergear.
• Requerir al menos una review aprobatoria.
• Descartar aprobaciones obsoletas en nuevos commits.
• Requerir verificaciones de status.
• Requerir historia lineal.
• No permitir force pushes.
• No permitir eliminación directa.

gh api -X PUT repos/owner/repo/branches/main/protection \
  -F required_pull_request_reviews.required_approving_review_count=1 \
  -F required_status_checks.strict=true \
  -F enforce_admins=true

Paso 3: CODEOWNERS

# .github/CODEOWNERS
*               @org/maintainers
/infra/         @org/devops
/docs/          @org/docs-team
*.sql           @org/dba

Paso 4: plantilla de PR

# .github/PULL_REQUEST_TEMPLATE.md
## Resumen
Breve descripción del cambio.

## Por qué
Contexto, enlaces a issues.

## Cómo se probó
- [ ] Tests unitarios añadidos/actualizados
- [ ] Smoke test manual
- [ ] CI verde

## Capturas / videos (solo UI)

## Riesgo y rollback
Cualquier cosa que los revisores deban preocuparse.

Paso 5: verificaciones automatizadas

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test

Paso 6: integraciones de bots

• Dependabot / Renovate.
• Action de gitleaks.
• Codecov o Coveralls.
• danger.js o danger-rb.

Paso 7: convenciones de review

# CONTRIBUTING.md
## Para autores
- Branch desde main.
- Mantén PRs bajo 400 líneas si es posible.
- Auto-revisa el diff antes de pedir review.
- Vincula el ticket.
- Aborda cada comentario del revisor.

## Para revisores
- Responde dentro de un día laboral.
- Distingue comentarios bloqueantes de sugerencias.
- Aprueba o solicita cambios.
- Confía en el juicio del autor sobre estilo.

Paso 8: convenciones de comentarios

• nit: sugerencia menor estilística.
• question: buscando aclaración.
• suggestion: cambio propuesto.
• blocker: debe ser abordado.
• praise: resaltando algo bien hecho.

Paso 9: revisar pequeño, revisar a menudo

Paso 10: manejar desacuerdos

1. Discutir en comentarios del PR.
2. Escalar a un tercer revisor.
3. Decidir vía discusión de equipo.

Paso 11: higiene post-merge

• Auto-eliminar branches mergeados.
• Ejecutar barridos periódicos de PR.
• Rastrear tiempo de ciclo de PR.

Paso 12: mejora continua