Cosa otterrai

Configurerai un workflow di code review che scala da tre a trenta contributori.

Passo 1: scegliere un modello

Il modello dominante nel 2026 e GitHub Flow.

Passo 2: protezione branch

• Richiedere una pull request.
• Richiedere almeno una review approvante.
• Scartare approvazioni stale.
• Richiedere status check.
• Richiedere storia lineare.
• Vietare force push.
• Vietare cancellazione diretta.

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

Passo 3: CODEOWNERS

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

Passo 4: template PR

# .github/PULL_REQUEST_TEMPLATE.md
## Summary
Brief description of the change.

## Why
Context, links to issues.

## How tested
- [ ] Unit tests added/updated
- [ ] Manual smoke test
- [ ] CI green

## Screenshots / videos (UI only)

## Risk and rollback
Anything reviewers should worry about.

Passo 5: check automatizzati

# .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

Passo 6: integrazioni bot

• Dependabot / Renovate.
• gitleaks.
• Codecov o Coveralls.
• danger.js.

Passo 7: convenzioni di review

# CONTRIBUTING.md
## For authors
- Branch off main; name `type/PROJ-1234-description`.
- Keep PRs under 400 lines if possible.
- Self-review the diff before requesting review.
- Link the ticket; include screenshots for UI changes.
- Address every reviewer comment.

## For reviewers
- Respond within one working day.
- Distinguish blocking comments from suggestions.
- Approve or request changes.
- Trust the author's judgement on style.

Passo 8: convenzioni commenti

• nit: suggerimento stilistico minore.
• question: chiarimento.
• suggestion: cambio proposto.
• blocker: deve essere indirizzato.
• praise: chiamare qualcosa fatto bene.

Passo 9: revisionare piccolo, revisionare spesso

• PR sopra le 400 righe ricevono review meno accurate.
• Incoraggiare PR stacked.
• Auto-revisione prima di richiedere.

Passo 10: gestire disaccordi

1. Discutere nei commenti PR.
2. Escalation a un terzo revisore.
3. Decidere offline.

Passo 11: igiene post-merge

• Auto-cancellare branch mergati.
• Pulizia periodica delle PR.
• Tracciare il tempo di ciclo PR.

Passo 12: miglioramento continuo

Tenere un retro trimestrale sul processo di review.