Genehmigen / Genehmigung erhalten: Was es ist, Approval und Code Review in Git

Was ist Pull-Request-Genehmigung

Die Genehmigung ist eine positive Bewertung eines Pull Requests, was bedeutet, dass der Reviewer den Code geprüft, keine kritischen Probleme gefunden hat und die Änderungen als bereit für den Merge betrachtet. In der GitHub-Oberfläche ist dies der grüne „Approve“-Button auf der PR-Seite. Nach der Genehmigung kann der Autor (oder jedes Mitglied mit Schreibrechten) den Merge durchführen.

Der Genehmigungsprozess ist Teil der Branch Protection Rules. Die Repository-Besitzer konfigurieren die Pflichtanforderungen: Mindestanzahl von Genehmigungen (z. B. 1 oder 2), wer genehmigen darf (Codebesitzer, Teammitglieder) und ob der PR nach Änderungen erneut genehmigt werden muss (Dismiss stale reviews). Ohne Regelkonfiguration ist die Genehmigung optional, aber in professionellen Teams ist sie Pflicht.

GitLab verwendet einen ähnlichen Mechanismus namens Approval Rules. In GitLab kann konfiguriert werden, wie viele Genehmigungen von verschiedenen Gruppen erforderlich sind (z. B. 2 von Backend-Entwicklern und 1 von DevOps). Nach Erhalt aller erforderlichen Genehmigungen wird der PR automatisch für den Merge freigeschaltet, sofern die CI/CD-Pipeline grün ist.

Review-Typen: Approve, Request Changes, Comment

GitHub und GitLab haben drei Arten von Reviews, die ein Reviewer zu einem Pull Request hinterlassen kann. Jeder Typ hat einen anderen Status und unterschiedliche Konsequenzen für den Merge-Prozess. Approve ist grün, Request Changes ist rot, Comment ist neutral grau. Die Wahl hängt von der Codequalität und der Bereitschaft der Änderungen für die Annahme ab.

Approve — der Reviewer bestätigt: Der Code ist korrekt geschrieben, erfüllt die Standards, enthält keine offensichtlichen Fehler und kann gemerged werden. Approve bedeutet nicht, dass der Code perfekt ist — nur, dass er gut genug für die Produktion ist. Wenn es kleinere Anmerkungen gibt (Stil, Benennung), können sie als Kommentare ohne Blockierung des PR hinterlassen werden.

Request Changes — der Reviewer findet Probleme, die vor dem Merge behoben werden müssen: Logikfehler, Schwachstellen, Architekturverstöße, fehlende Tests. Nach Request Changes wird der PR blockiert, und zur Freischaltung ist eine erneute Genehmigung durch denselben Reviewer erforderlich (wenn die Option Dismiss stale reviews bei neuen Commits aktiviert ist).

• Approve — Code ist bereit für den Merge, kann nach bestandenem CI gemerged werden.
• Request Changes — zwingende Korrekturen, PR ist bis zum erneuten Review blockiert.
• Comment — allgemeine Anmerkung oder Vorschlag ohne Blockierung des PR.

Konfiguration von Genehmigungsregeln im Repository

Die Branch Protection Rules sind GitHub’s Mechanismus zur Kontrolle der Merge-Qualität. Sie werden in Settings → Branches für jeden geschützten Branch (main, develop, release/*) konfiguriert. Hauptparameter: Anzahl der erforderlichen Genehmigungen, Codebesitzer (CODEOWNERS), obligatorische CI/CD-Prüfung und Verbot von Push ohne PR.

Der Parameter Dismiss stale pull request approvals entfernt automatisch Genehmigungen, wenn ein neuer Commit zum PR hinzugefügt wird. Dies stellt sicher, dass die Reviewer genau die Version des Codes genehmigen, die gemerged wird. Ohne diese Einstellung könnte der Autor nach der Genehmigung neuen Code hinzufügen, der ohne erneute Prüfung in main landen würde.

CODEOWNERS — eine Datei im Repository-Stammverzeichnis, die Verantwortliche für verschiedene Verzeichnisse zuweist. Wenn ein PR Dateien betrifft, die einem Codebesitzer gehören, wird dessen Genehmigung obligatorisch. CODEOWNERS ermöglicht die Verteilung von Verantwortungsbereichen: iOS-Entwickler sind für Swift-Dateien verantwortlich, DevOps für Docker-Konfigurationen, Tester für Testszenarien.

# Beispiel CODEOWNERS-Datei im Repository-Stamm

# iOS-Entwickler besitzen Swift-Code
*.swift @team/ios-developers

# DevOps besitzt CI/CD-Konfiguration
.github/workflows/* @devops-team

# QA-Ingenieure prüfen Tests
**/tests/* @qa-engineers

# Standardbesitzer für alles andere
* @tech-leads

Code Review vor der Genehmigung: Was prüfen

Das Code Review vor der Genehmigung ist eine systematische Code-Prüfung, kein flüchtiger Blick auf den Diff. Ein qualitativ hochwertiges Code Review umfasst die Prüfung von Architektur, Logik, Stil, Tests und Sicherheit. Ohne diese Prüfung wird die Genehmigung zur Formalität und nicht zum Qualitätskontrollwerkzeug.

Was zuerst geprüft wird: die Logik der Änderungen — löst der Code die Aufgabe, gibt es Nebenwirkungen, ist die Behandlung von Grenzfällen korrekt. Tests — decken die neuen Tests alle Szenarien ab, bestehen die vorhandenen Tests nach den Änderungen? Sicherheit — gibt es SQL-Injections, XSS, Lecks sensibler Daten?

Was nicht Gegenstand des Reviews sein sollte: Formatierungsstil (dafür gibt es Linter und Formatierer), vorab getroffene Architekturentscheidungen (sie werden vor dem Schreiben des Codes besprochen). Wenn ein Review 400 Zeilen überschreitet oder länger als eine Stunde dauert, ist dies ein Zeichen, dass die Aufgabe zu groß ist und zerlegt werden muss. Beste Review-Praktiken — Portionen von 200–400 Zeilen innerhalb von 24 Stunden nach PR-Erstellung.

• Logik — Korrektheit der Lösung, Fehlerbehandlung, Grenzfälle.
• Tests — Abdeckung neuer Szenarien, bestehende Tests bestanden, keine flaky Tests.
• Sicherheit — keine Injections, Escaping der Ausgabe, Datenzugriffskontrolle.
• Leistung — Effizienz von Algorithmen, übermäßige Abfragen, Speicherlecks.
• Dokumentation — ist die Dokumentation aktualisiert, sind Kommentare in komplexen Abschnitten klar.

Workflow mit Genehmigung im Team

Ein typischer Workflow mit Genehmigung in einem Team von 5–10 Entwicklern sieht so aus: Ein Entwickler erstellt einen PR, weist Reviewer zu (normalerweise 1–2 Personen aus dem Team oder Codebesitzer), CI/CD führt automatische Prüfungen durch. Nach Erhalt aller erforderlichen Genehmigungen und grünem CI führt der Autor den Merge durch. Die Zeit von der PR-Erstellung bis zum Merge beträgt je nach Komplexität durchschnittlich 2 Stunden bis 2 Tage.

GitHub Actions ermöglichen die Automatisierung des Merges nach der Genehmigung. Wenn Branch-Regeln konfiguriert sind, blockiert GitHub den Merge automatisch, bis alle Bedingungen erfüllt sind. Einige Teams verwenden bors-ng oder Mergify — Bots, die PRs automatisch mergen, nachdem alle Genehmigungen eingegangen sind und CI bestanden wurde. Dies beschleunigt den Prozess und eliminiert den menschlichen Faktor beim Merge.

Ein moderner Ansatz ist trunk-based development mit kurzlebigen Branches. In diesem Workflow muss die Genehmigung innerhalb weniger Stunden eingehen, sonst gilt die Aufgabe als veraltet und erfordert eine erneute Synchronisation mit main. Teams mit einer hohen Review-Kultur streben eine Genehmigungszeit von nicht mehr als 4 Arbeitsstunden an.

Fehler bei der Genehmigung und wie man sie vermeidet

Der häufigste Fehler ist die formale Genehmigung ohne tatsächliche Code-Prüfung. Wenn ein PR groß ist oder eine Deadline naht, kann der Reviewer Approve klicken, ohne die Änderungen zu prüfen. Dies entwertet den gesamten Code-Review-Prozess. Lösung: Eine Grenze für die PR-Größe festlegen (nicht mehr als 400 Zeilen) und Code-Analyse-Tools (SonarQube, CodeClimate) für automatische Prüfungen verwenden.

Der zweite Fehler ist eine übermäßig strenge Genehmigung. Die Erwartung von perfektem Code blockiert die Entwicklung. Reviewer verlangen manchmal die Korrektur von stilistischen Anmerkungen, die die Qualität nicht beeinflussen. Lösung: Klare Trennung zwischen zwingenden Anmerkungen (blockierend) und optionalen Vorschlägen (Kommentare). GitHub erlaubt die explizite Angabe, ob ein Kommentar blockierend ist.

Der dritte Fehler ist die Genehmigung ohne Prüfung von CI/CD. Auch wenn der Code korrekt aussieht, könnte er nicht kompilieren oder in Tests fehlschlagen. Konfigurierte Branch Protection blockiert den Merge automatisch bei rotem CI, aber einige Teams deaktivieren diesen Schutz aus Gründen der Geschwindigkeit. Lösung: Vor der Genehmigung immer den CI-Status prüfen und niemals einen PR mit roter Pipeline genehmigen.

• Formale Genehmigung — fehlende tatsächliche Code-Prüfung. Lösung: Limit von 400 Zeilen pro PR.
• Übermäßige Strenge — Blockierung aufgrund stilistischer Anmerkungen. Lösung: Aufteilung in blockierend und optional.
• Ignorieren von CI — Genehmigung bei roter Pipeline. Lösung: Immer den Teststatus prüfen.
• Autorenzuweisung — Genehmigung durch den PR-Autor. Lösung: Branch Protection gegen den Autor konfigurieren.