Was Sie erreichen werden

Sie werden einen Code-Review-Workflow konfigurieren, der von drei bis dreissig Mitwirkenden skaliert.

Schritt 1: ein Modell wahlen

Das dominante Modell im Jahr 2026 ist GitHub Flow.

Schritt 2: Branch-Schutz

• Eine Pull Request erfordern.
• Mindestens einen genehmigenden Review erfordern.
• Veraltete Genehmigungen verwerfen.
• Status-Checks erfordern.
• Lineare Historie erfordern.
• Force-Pushes verbieten.
• Direktes Loschen verbieten.

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

Schritt 3: CODEOWNERS

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

Schritt 4: PR-Template

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

Schritt 5: automatisierte Checks

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

Schritt 6: Bot-Integrationen

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

Schritt 7: Review-Konventionen

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

Schritt 8: Kommentar-Konventionen

• nit: kleinere stilistische Anregung.
• question: Klarung suchen.
• suggestion: vorgeschlagene Anderung.
• blocker: muss adressiert werden.
• praise: etwas gut Gemachtes hervorheben.

Schritt 9: klein reviewen, oft reviewen

• PRs uber 400 Zeilen erhalten weniger grundliche Reviews.
• Stacked PRs ermutigen.
• Selbstuberprufung vor Anforderung.

Schritt 10: Meinungsverschiedenheiten handhaben

1. In PR-Kommentaren diskutieren.
2. Eskalation zu einem dritten Reviewer.
3. Offline entscheiden.

Schritt 11: Post-Merge-Hygiene

• Gemergte Branches automatisch loschen.
• Periodisches Aufraumen veralteter PRs.
• PR-Zykluszeit verfolgen.

Schritt 12: kontinuierliche Verbesserung

Vierteljahrliches Retro zum Review-Prozess halten.