Pull Requests und Code Reviews

In L8 hast du Workflows kennengelernt. Im Zentrum von Feature Branch + Gitflow steht eine Praktik: der Pull Request (PR) – auch „Merge Request" in GitLab. Er ist die moderne Form der Code-Übergabe im Team. Diese Lektion zeigt, was ein PR ist, wie ein Code Review abläuft und wie man als Reviewer und Author gute Praktiken anwendet.

Code Reviews sind nicht nur eine Formalität – Studien zeigen, dass sie Bug-Raten halbieren und Wissenstransfer im Team beschleunigen. Wer reviewen kann, ist im Team wertvoll. Eine Schlüssel-Kompetenz für FIAEs.

1) Was ist ein Pull Request?

Ein Pull Request ist ein formaler Antrag, eigene Änderungen (auf einem Branch) in einen Ziel-Branch (meist main) zu mergen. Der Name kommt daher: „Bitte zieh meinen Branch in deinen rein". Auf GitHub/Bitbucket heißt es Pull Request, auf GitLab Merge Request, auf Azure DevOps Pull Request. Funktional dasselbe.

Ein PR ist nicht nur „Code reinkopieren", sondern eine Diskussionsbühne:

• Änderungen werden Zeile für Zeile sichtbar (Diff-View).
• Reviewer können Kommentare auf einzelne Zeilen schreiben.
• Automatisierte Checks (CI, Tests, Linter) laufen automatisch.
• Es gibt Approval/Request-Changes-Stati.
• Nach Approval kann der Author oder Reviewer mergen.

2) Ein PR im GitHub-Stil

So sieht ein typischer Pull Request aus:

3) PR-Lifecycle

Ein PR durchläuft typische Stati:

4) Wie schreibt man einen guten PR?

Als Author hilfst du den Reviewern, indem du:

5) PR-Template – Vorlagen nutzen

Viele Teams definieren eine .github/pull_request_template.md. Wenn ein PR erstellt wird, ist diese Vorlage automatisch ausgefüllt:

## Was wurde geändert?

Kurze Beschreibung der Änderung.

## Warum?

Kontext, Motivation, Issue-Bezug.
Closes #(issue-nummer)

## Wie testen?

Schritt-für-Schritt-Anleitung:
1. ...
2. ...

## Screenshots (falls UI-Änderung)

(hier rein)

## Checklist

- [ ] Tests hinzugefügt/aktualisiert
- [ ] Doku aktualisiert
- [ ] Selbst-Review durchgeführt
- [ ] Build läuft lokal
- [ ] Conventional Commit Message

Solche Templates sparen viel Zeit und stellen sicher, dass nichts vergessen wird. Auf GitLab heißt das Ganze „Merge Request Template", funktioniert genauso.

6) Code Review als Reviewer

Wenn du einen PR reviewst, fragst du dich:

7) Kommunikation im Review – Tonfall

Reviews sind Kommunikation zwischen Menschen. Schlechter Tonfall vergiftet Teams. Beispiele:

✗ Schlecht: „Das ist schlecht.", „Wieso machst du das so?", „Falsch."

✓ Gut: „Hier könnten wir Method-X verwenden, das wäre konsistenter mit dem Rest des Codes.", „Idee: was hältst du davon, die Konstante auszulagern?", „Gefällt mir – kleine Anmerkung: typo in Zeile 42."

Faustregeln:

• Konkret werden, nicht allgemein.
• Fragen statt Vorwürfe. „Warum so?" statt „Falsch."
• Vorschläge machen, nicht nur Probleme.
• Lob teilen. Gute Stellen explizit hervorheben.
• Code, nicht Person, kritisieren. „Dieser Code …" statt „Du …".

Eine bekannte Heuristik: Conventional Comments – Kommentare beginnen mit einem Label: suggestion:, nitpick:, question:, praise:, blocker:. Das macht klar, wie wichtig der Kommentar ist.

8) Approval-Strategien

Wann gilt ein PR als „genehmigt"? Verschiedene Modelle:

• Single Approval: ein Reviewer reicht. Schnell, OK für kleine Teams oder unkritische Repos.
• Two-Person-Rule: zwei Approvals nötig. Standard in vielen Enterprise-Settings.
• Code Owners: bestimmte Dateien können nur von benannten Reviewern approved werden. Konfiguriert via CODEOWNERS-Datei.
• Optional/Mandatory: manche Reviewer sind Pflicht, andere optional.

Auf GitHub stellst du das in Settings → Branches → Branch protection rules ein. Auf GitLab unter Settings → Repository → Merged request approvals.

9) Automatisierte Checks – CI im PR

Vor dem menschlichen Review machen Maschinen die ersten Checks. Typisch sind:

• Build: kompiliert der Code überhaupt?
• Tests: alle Unit/Integration-Tests grün? (vgl. K52)
• Linter: ESLint, Checkstyle, Pylint sauber? (vgl. K53 L6)
• Coverage: mindestens X % Coverage?
• Security: npm audit / Snyk / Dependabot keine kritischen Findings?
• SonarQube: keine neuen Issues? Quality Gate grün? (vgl. K53 L9)

Rote Checks blockieren in modernen Setups den Merge. Erst alles grün, dann menschlicher Review. Das spart Reviewer-Zeit für relevante Themen.

10) Praxis-Tipps

• Klein halten. 200 Zeilen sind besser als 800. Reviewer-Müdigkeit ist real.
• Selbst-Review zuerst. Bevor du andere darum bittest – schau selbst den Diff an. Du findest die Hälfte der Bugs.
• Schnell reagieren. Wenn jemand auf dein Review wartet, blocking ihn. Daily Review-Slots einplanen.
• Reviewer rotieren. Nicht immer dieselben Reviewer – Wissensverteilung wichtig.
• Bei großem Refactoring: erst PR mit Plan (Beschreibung), dann den eigentlichen PR. Spart Diskussionen.
• Niemand reviewt eigenen Code. Auch wenn du der Senior bist – externes Auge ist wichtig.

Zusammenfassung

Pull Request (auf GitLab: Merge Request) = formaler Antrag, einen Branch in den Ziel-Branch zu mergen. Zentrale Bühne für Code Review. PR-Lifecycle: Draft → Open → Approved/Changes Requested → Merged/Closed. Guter PR: klarer Titel, Beschreibung mit Was/Warum/Wie-testen, Issue-Bezug, max. ~400 Zeilen Diff, eine logische Einheit. CI-Checks automatisch (Build, Tests, Linter, Coverage, SonarQube). Review-Fokus: Funktion, Lesbarkeit, Tests, Smells, Sicherheit, Performance. Tonfall: konstruktiv, fragend statt urteilend, Code kritisieren – nicht Person. Branch Protection erzwingt PR-Flow technisch. Nächste Lektion: IHK-Aufgaben Git.