GitHub Flow — MQA Governance Portal

Executive Summary

Kurz: Code-Review und CI vor Production.

Warum relevant: Keine ungeprüften Live-Änderungen.

Kosten: GitHub Team ~€4/User/Monat ggf.

Status: CI live; Branch Protection offen.

Entscheidung nötig: GitHub Team/Pro falls Branch Protection nötig

Executive Overview — all summaries for decision-makers.

Stand: August 2026 · Repo: MQA-Group/MQA-Governance-Portal (privat)

Branch-Modell

main ──────────────► Production (portal.mqa.group / api.mqa.group)
  ▲
  │  PR nach Staging-Smoke-Test
  │
develop ───────────► Staging (mqa-*-staging.onrender.com)
  ▲
  │  PR mit Review + CI
  │
feature/* ─────────► Entwicklung
fix/*
chore/*

Branch	Zweck	Auto-Deploy
main	Production, stabil	Render Production
develop	Integration / Staging	Render Staging
feature/*, fix/*, chore/*	Kurzlebige Arbeit	—

Regel: Nie direkt auf main pushen. Immer PR → develop → nach Test PR → main.

Pull-Request-Prozess

1. Branch von develop erstellen: git checkout develop && git pull && git checkout -b feature/kurz-beschreibung
2. Commits mit Conventional Commits:
   • feat: neues Feature
   • fix: Bugfix
   • chore: Tooling, CI, Doku
   • docs: nur Dokumentation
   • security: Hardening
3. PR gegen develop öffnen — Template ausfüllen
4. CI Success muss grün sein (Required Check, siehe unten)
5. Mind. 1 Review (Team-Disziplin; Branch Protection siehe unten)
6. Merge (Squash bevorzugt für saubere History)
7. Staging testen → DEPLOYMENT-CHECKLIST
8. Release PR: develop → main (nur nach Staging-OK)

CI / GitHub Actions

Workflow: .github/workflows/ci.yml

Job	Pflicht	Hinweis
CI Success	✅ Ja	Aggregierter Gate-Check für Branch Protection
Frontend Build	✅ Ja	Lint/Test advisory (continue-on-error)
Backend Build	✅ Ja	Lint/Test advisory
Security audit	Advisory	npm audit --audit-level=high

Path-Filter: Nur betroffene Jobs laufen (Frontend/Backend getrennt).

Dependabot: .github/dependabot.yml — wöchentliche npm-Updates (Mo 06:00 Berlin).

Branch Protection (manuell einrichten)

Hinweis: Private Repos ohne GitHub Pro/Team können Rulesets/Branch Protection per API nicht erzwingen. Bis Upgrade: Team-Disziplin + PR-Template.

Nach GitHub Pro / Team Plan:

main

• Require PR before merge
• Required status check: CI Success
• Require 1 approval
• Dismiss stale reviews
• Do not allow bypass (Admins optional)
• Restrict pushes to main

develop

• Require PR before merge
• Required status check: CI Success
• 1 approval empfohlen

Einrichtung: Repo → Settings → Branches → Add branch ruleset (oder Classic protection).

Secrets & Security

• Keine Secrets in Commits, PRs oder Issues
• Env-Referenz: ENV-INVENTORY
• Render Secrets nur im Dashboard / Blueprint sync: false

Release nach Production

1. PR develop → main mit Release-Notizen (Summary im PR-Body)
2. Nach Merge: Render deployt automatisch (~5–10 Min)
3. Smoke-Test Production: DEPLOYMENT-CHECKLIST
4. Bei DB-Änderungen: Migrationen sind im Backend-Entrypoint (prisma migrate deploy) — kein manuelles Seed in Prod

Hotfix (Ausnahme)

Kritische Production-Fixes:

git checkout main && git pull
git checkout -b fix/kurz-beschreibung
# fix, commit, PR → main
# danach: main → develop mergen (Back-merge)

Nützliche Befehle

# CI lokal spiegeln
npm ci && npm run build
cd backend && npm ci && npm run build

# PR erstellen
gh pr create --base develop --title "feat: …" --body-file .github/pull_request_template.md

# Status Checks
gh pr checks

Verwandte Docs

• OPS-ECOSYSTEM — Architektur
• STAGING-STATUS — Staging-Ressourcen
• OPS-ROADMAP — Offene Ops-Punkte