Viele Review-Probleme entstehen nicht erst im Code, sondern schon beim Pull Request selbst: zu großer Umfang, unklare Beschreibung, fehlende Testhinweise oder überraschende Seiteneffekte. Diese Checkliste hilft dabei, einen Pull Request so vorzubereiten, dass Reviewer schnell verstehen, worum es geht und worauf sie achten sollen.
1. Umfang klein und nachvollziehbar halten
Behandelt der Pull Request ein klar abgegrenztes Ziel? Unabhängige Refactorings, Formatierungsänderungen oder Nebenbaustellen sollten möglichst nicht mit derselben Änderung vermischt werden.
2. Ziel und Kontext beschreiben
Ist in wenigen Sätzen verständlich, welches Problem gelöst wird und warum die Änderung notwendig ist? Ein Reviewer sollte den fachlichen und technischen Kontext nicht erst aus mehreren Tickets zusammensuchen müssen.
3. Wichtige Änderungen hervorheben
Gibt es Stellen, auf die Reviewer besonders achten sollten? Neue Architekturentscheidungen, ungewöhnliche Workarounds, externe Abhängigkeiten oder bewusste Kompromisse gehören sichtbar in die Beschreibung.
4. Tests dokumentieren
Welche automatisierten und manuellen Prüfungen wurden durchgeführt? Bei relevanten Randfällen sollte erkennbar sein, wie sie getestet wurden und ob bekannte Einschränkungen bestehen.
5. Datenbank, Konfiguration und Migrationen nennen
Enthält die Änderung Migrationen, neue Umgebungsvariablen, Feature Flags oder Konfigurationsänderungen? Solche Voraussetzungen sollten nicht erst beim Deployment auffallen.
6. Risiken und Seiteneffekte prüfen
Welche bestehenden Funktionen könnten indirekt betroffen sein? Besonders bei gemeinsam genutzten Komponenten, Berechtigungen, Datenstrukturen oder Schnittstellen lohnt sich ein kurzer Hinweis auf mögliche Auswirkungen.
7. Screenshots oder Beispiele ergänzen, wenn sie helfen
Bei sichtbaren UI-Änderungen oder komplexem Verhalten können Screenshots, Beispielaufrufe oder kurze Vorher-nachher-Beschreibungen das Review deutlich beschleunigen.
8. Vor dem Review selbst gegenlesen
Ist die Beschreibung noch aktuell? Sind Debug-Ausgaben, temporäre Kommentare und unbeabsichtigte Dateien entfernt? Ein kurzer eigener Diff-Check spart oft mehrere Review-Runden.
9. Review-Bereitschaft eindeutig machen
Ein Pull Request sollte erst dann als reviewbereit markiert werden, wenn die vereinbarten Mindestprüfungen erfolgt sind. Unfertige Zwischenstände gehören als Draft erkennbar gemacht.
10. Merge-Voraussetzungen klären
Sind alle erforderlichen Checks erfolgreich, Konflikte gelöst und blockierende Review-Kommentare geklärt? Der Merge sollte kein Ratespiel sein, sondern der letzte Schritt eines nachvollziehbaren Ablaufs.