PRs, Reviews, Releases: Ein Workflow, der nicht alle nervt (auch in kleinen Teams)

Ein kleiner Team-Workflow muss vor allem eins können: schnell sein, ohne dass Qualität wegbröselt. Das scheitert fast immer an denselben Dingen: PRs sind zu groß, Reviews kommen zu spät, Releases sind unplanbar und CI ist Deko.

Hier ist ein Workflow, der in 2–8 Personen-Teams gut funktioniert, ohne GitFlow-Museum und ohne „wir machen jetzt Scrum für Reviews“.

Warum Teams an PRs sterben

1) Review-Stau ist ein Systemproblem

Wenn Reviews optional sind, sind sie in stressigen Phasen das Erste, was wegfällt. Ergebnis: PRs werden riesig, Merges riskant, Releases zäh.

2) Große PRs sind der Feind

Große PRs killen Kontext, erhöhen Fehlerrisiko und sorgen dafür, dass Reviewer aussteigen. Und wenn Reviewer aussteigen, bekommst du „LGTM“ ohne echte Prüfung. Das ist kein Review, das ist ein Ritual.

3) Releases werden zum Event

Wenn Releases „besondere Tage“ sind, sind sie automatisch stressig. Ziel ist: Releases sind langweilig. Das ist gut.

Der Workflow: PRs, Reviews, Releases – konkret und kleinteam-tauglich

1) Branching: „Trunk-based light“ als Default

Für kleine Teams funktioniert meistens: kurzlebige Branches + Main immer deploybar. Kein Langzeit-GitFlow, außer du hast einen echten Grund.

• Branch: pro Ticket/Change
• Lebensdauer: Stunden bis wenige Tage
• Feature Flags: für unfertige UI/Flows (damit du trotzdem mergen kannst)

2) PR-Regeln: klein, fokussiert, beschreibbar

• Eine Sache pro PR: kein „und wenn wir schon dabei sind“.
• Maximalgröße: als Faustregel: so, dass ein Review in 15–30 Minuten möglich ist.
• PR-Beschreibung muss beantworten: Was ändert sich? Warum? Wie testen? Risiko?
• Proof: Screenshot/kurzer Test-Hinweis, wenn UI oder Verhalten betroffen ist.

3) Review-Regeln: schnell, freundlich, mit klaren Levels

• Review-SLA: z.B. „innerhalb 1 Arbeitstag“ (sonst staut sich alles).
• 2 Review-Modi: „Blocker“ (muss fix) vs „Nit“ (nice-to-have).
• Style-Fragen automatisieren: Formatter/Linter, damit Menschen über Logik reden, nicht über Tabs.
• Reviewer-Rotation: damit nicht immer dieselbe Person der Flaschenhals ist.

4) Merge-Regeln: CI gewinnt, nicht Meinung

Wenn Tests rot sind, wird nicht gemerged. Punkt. Branch Protection muss nicht maximal streng sein, aber grüne Checks als Minimum sind Pflicht.

• Merge-Standard: squash merge (ein PR = ein Commit in Main) für sauberen Verlauf.
• Fallback: merge commits, wenn du bewusst die PR-Historie behalten willst.
• Fast-Forward-Chaos vermeiden: Hauptsache, du hast einen Standard.

5) Releases: Rhythmus + Automatik + Notfallweg

• Release-Rhythmus: z.B. 1–2x pro Woche oder täglich (wenn du’s kannst).
• Release Notes: automatisch aus PR-Titeln/Conventional Commits generieren.
• Hotfix-Flow: minimaler Fix, direkt durch denselben PR/CI Prozess (kein „SSH und beten“).

Mini-Regel für Release-Sanity:
Wenn du nicht jederzeit releasen kannst, bist du zu lange nicht gereleased.

Welche Branching-Strategie passt? (kleine Teams, ehrlich)

So setzt du’s um

7-Tage-Plan (ohne Overhead)

1. Tag 1: Merge-Standard festlegen (squash oder merge) + Branch-Naming.
2. Tag 2: Branch Protection light: main geschützt, CI muss grün sein.
3. Tag 3: PR-Template einführen (Was/Warum/Test/Risiko).
4. Tag 4: Review-SLA festlegen + Reviewer-Rotation.
5. Tag 5: „Blocker vs Nit“-Regel + Formatter/Linter als Pflicht.
6. Tag 6: Release-Rhythmus festlegen + Release Notes Standard.
7. Tag 7: Hotfix-Flow testen (künstlicher Bug → sauberer Fix → Release).

Mini-PR-Template (kopierbar)

- Was ändert sich?
- Warum?
- Wie testen? (Schritte / Commands)
- Risiko / Rollback?
- Screenshots (wenn UI)

Typische Fehler & wie du sie vermeidest

• Fehler: PRs werden riesig. Fix: „Review in 30 Minuten“ als Größenlimit, sonst splitten.
• Fehler: Reviews dauern Tage. Fix: Review-SLA + Rotation + WIP-Limit (nicht 5 PRs parallel anfangen).
• Fehler: CI rot, trotzdem merge. Fix: Branch Protection: grün oder raus.
• Fehler: Release ist ein Event. Fix: Rhythmus + Automatik + kleine Changes.
• Fehler: Diskussionen über Style im Review. Fix: Formatter/Linter, Review = Logik, Risiko, Verständlichkeit.

Fazit: Weniger nerven, mehr liefern

Ein Workflow nervt dann, wenn er unklar ist. Mit kleinen PRs, schnellen Reviews, CI als Gate und Release-Routine wird’s plötzlich entspannt. Nicht weil ihr „perfekt“ seid, sondern weil das System euch schützt.

Nächster Schritt: Setz heute Branch Protection light + PR-Template auf. Das sind 30 Minuten, die dir Wochen Stress sparen.

FAQ