Pull Request: Was es ist, der Erstellungsprozess und Code-Review

Was ist ein Pull Request?

Pull Request (PR) ist eine formelle Anfrage, Änderungen von einem Branch in einen anderen innerhalb eines verteilten Versionskontrollsystems aufzunehmen. Der PR ist ein zentrales Element der kollaborativen Entwicklung auf den Plattformen GitHub, GitLab und Bitbucket und kombiniert Code-Diskussion, automatisierte Tests und den Änderungsgenehmigungsprozess.

Der Name „Pull Request“ spiegelt das Wesen der Operation wider: Ein Entwickler bittet (request) den Repository-Besitzer, seine Änderungen zu „pullen“ (zu holen). Der Begriff wurde 2008 von GitHub eingeführt — davor existierte ein ähnlicher Mechanismus in Form von Patches und Merge Requests (GitLabs Begriff). Heute ist der PR der De-facto-Standard für die Team-Entwicklung mit Git.

Laut GitHub Octoverse, 2025 erfordern 89% der Open-Source-Projekte die Erstellung eines PRs für Änderungen. In der Unternehmensentwicklung erreicht dieser Wert 95%. Der PR ist nicht nur ein technisches Werkzeug, sondern Teil der Entwicklungskultur geworden: Durch PRs erfolgen Wissensaustausch, Fehlererkennung und Abstimmung architektonischer Entscheidungen.

Komponenten eines Pull Requests

Ein typischer PR besteht aus Titel, Beschreibung, Liste der geänderten Dateien (Diff), Reviewer-Kommentaren und CI-Prüfstatus. Jeder PR ist mit einem bestimmten Quell- und Zielbranch verknüpft und kann nach der Zusammenführung automatisch gelöscht werden.

Wie erstellt man einen Pull Request?

Einen PR erstellen beginnt mit der Veröffentlichung eines Feature-Branchs im entfernten Repository. Nach dem Push öffnet der Entwickler einen PR über die Plattformoberfläche oder per CLI (gh, glab). Sehen wir uns den Prozess am Beispiel von GitHub an.

Branch pushen und PR öffnen

Der erste Schritt besteht darin, den Feature-Branch in das entfernte Repository zu pushen und einen Pull Request über die Weboberfläche oder die Befehlszeile zu erstellen.

# Feature-Branch erstellen und pushen
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# PR über GitHub CLI erstellen
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

Nach der Erstellung eines PRs führt GitHub automatisch CI-Pipelines (GitHub Actions) aus, prüft auf Konflikte mit dem Zielbranch und lädt Reviewer ein. Die PR-Beschreibungsvorlage kann über .github/PULL_REQUEST_TEMPLATE.md konfiguriert werden, damit alle PRs die erforderlichen Abschnitte enthalten: Ziel, Änderungen, Tests, zugehörige Aufgaben.

Beschreibung und Tagging

Eine qualitativ hochwertige PR-Beschreibung enthält: einen Link zur Aufgabe (Issue/Ticket), eine kurze Beschreibung der Änderungen, Testanweisungen und eine Liste der zugehörigen Änderungen. Labels (Bug, Feature, Refactoring) helfen bei der Kategorisierung des PRs, während Assignees und Reviewer automatisch über CODEOWNERS zugewiesen werden.

# Reviewer über CODEOWNERS zuweisen (Datei im Repository-Stammverzeichnis)
# Beispiel .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# PR mit Reviewer-Zuweisung über gh cli erstellen
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS ist ein Standardmechanismus von GitHub/GitLab zur automatischen Zuweisung von Reviewern basierend auf geänderten Dateien. Beispielsweise weisen Änderungen im Verzeichnis src/auth/ automatisch team-auth und senior-dev als Reviewer zu. Dies beschleunigt den Prozess und stellt sicher, dass die richtigen Personen den PR sehen.

PR basierend auf Reviews aktualisieren

Nach Erhalt von Reviewer-Kommentaren nimmt der Entwickler Korrekturen im selben Feature-Branch vor und pusht neue Commits — der PR wird automatisch aktualisiert. Es ist wichtig, den Verlauf in einem veröffentlichten Feature-Branch nicht umzuschreiben (Rebase), wenn der PR bereits geöffnet ist, da dies die Links zu bestimmten Commits in Kommentaren zerstört.

# Änderungen basierend auf Reviewer-Kommentaren vornehmen
git checkout feature/biometric-auth
# Code korrigieren
git commit -m "fix: handle biometric timeout per review"
git push

# PR wird automatisch aktualisiert
# Nach Genehmigung — PR über GitHub-Oberfläche zusammenführen

Der Code-Review-Prozess

Das Code-Review ist ein zentrales Element eines Pull Requests. Der Reviewer prüft die Änderungen auf Korrektheit, Codestil, Sicherheit und architektonische Konsistenz. Ein qualitativ hochwertiges Review verhindert nicht nur Fehler, sondern verbreitet auch Wissen über die Codebasis im Team.

Die Engineering Practices von Google (2025) empfehlen die folgenden Grundsätze für Code-Reviews: Der Reviewer sollte den Kontext der Änderungen verstehen, spezifische Empfehlungen statt allgemeiner Anmerkungen geben und technische von stilistischen Kommentaren trennen. Die Review-Zeit sollte 24 Stunden ab dem Zeitpunkt der PR-Erstellung nicht überschreiten.

Für die mobile Entwicklung umfasst das Code-Review spezifische Prüfungen: Kompatibilität mit targetSdk, korrekte Lifecycle-Behandlung (Android) / View-Lifecycle (iOS), Abwesenheit von Speicherlecks (LeakCanary, Instruments), Dark-Theme-Unterstützung und Lokalisierung. Diese Prüfungen können durch Linter und Detekt/ktlint automatisiert werden.

Arten von Kommentaren

PR-Plattformen unterstützen drei Arten von Kommentaren: allgemeine (zum gesamten PR), zeilenbezogene (zu einer bestimmten Codezeile) und Vorschläge (mit Ersatzcode). Vorschläge ermöglichen die Anwendung von Änderungen mit einem Klick, was den Prozess beschleunigt und die Anzahl der Iterationen reduziert.

Nachdem alle Kommentare gelöst wurden und die CI-Prüfungen bestanden sind, sendet der Reviewer eine Genehmigung (Approved). Der PR kann zusammengeführt werden. GitHub und GitLab unterstützen Branch-Protection-Regeln: erforderliche Anzahl von Genehmigungen, obligatorische CI-Prüfungen und Verbot von Pushs in main ohne PR. Für mobile Projekte umfasst der Branch-Schutz auch die Build-Überprüfung: Ein PR kann nicht zusammengeführt werden, wenn die Anwendung nicht buildet (gradle build failed / xcodebuild failed).

Konfliktlösung im PR

Merge-Konflikte in einem Pull Request sind bei aktiver Teamarbeit eine häufige Situation. Plattformen bieten Konfliktlösung über die Weboberfläche (für einfache Konflikte) oder empfehlen eine lokale Lösung. GitHub Actions überprüft bei jedem Push in den Feature-Branch automatisch die Merge-Fähigkeit und markiert den PR als konfliktreich, wenn eine Zusammenführung nicht möglich ist.

Pull Request Best Practices

Effektive Pull Requests beschleunigen das Code-Review und reduzieren die Anzahl der Fehler. Eine SmartBear-Studie (2025) zeigte, dass PRs mit bis zu 200 Codezeilen zweimal mehr aussagekräftige Kommentare erhalten als PRs mit über 1000 Zeilen, und die Review-Zeit sich um das Dreifache verkürzt.

• Kleine PRs — die optimale Größe liegt bei 100–300 Zeilen. Teilen Sie große PRs in logische Teile auf: Jeder PR löst eine Aufgabe. Dies vereinfacht das Review und reduziert die Wahrscheinlichkeit von Konflikten
• Klare Beschreibung — Titel nach Conventional Commits (feat:, fix:, refactor:), der Body enthält „was und warum“ statt „wie“ (der Code spricht für sich). Vorlage: Ziel → Änderungen → Tests → zugehörige Issues
• Schnelles Feedback — Review innerhalb von 24 Stunden. Wenn ein PR länger als einen Tag wartet, verliert das Team den Kontext und die Anzahl der Merge-Konflikte steigt
• Automatisierung — Linter, Formatierer und Tests sollten bei der PR-Erstellung automatisch ausgeführt werden. Lassen Sie keine Zusammenführung von PRs mit roten CI-Prüfungen zu
• Draft PR — für die frühzeitige Architekturdiskussion verwenden. Draft PR erfordert kein Review und kann nicht zusammengeführt werden, ermöglicht aber, Kollegen frühzeitig Code zu zeigen

Zusätzliche Praktiken: Erstellen Sie keine PRs am Freitagabend (niemand wird bis Montag reviewen), fordern Sie Reviews von 1–2 Personen an (mehr verlangsamt den Prozess ohne Qualitätssteigerung), verwenden Sie Squash Merge, um den Verlauf vor der Zusammenführung zu komprimieren. Für mobile Projekte wird außerdem empfohlen, in der PR-Beschreibung einen Link zum Test-Build (Firebase App Distribution / TestFlight) hinzuzufügen, damit der Reviewer die Änderungen in der laufenden Anwendung überprüfen kann.

Pull Request auf verschiedenen Plattformen

Die wichtigsten Plattformen für die Arbeit mit Pull Requests sind GitHub, GitLab und Bitbucket. Trotz des gemeinsamen Konzepts hat jede Funktionen, die bei der Auswahl eines Tools für das Team zu berücksichtigen sind.

GitHub ist die beliebteste Plattform mit der größten Community, Actions für CI/CD und einem umfangreichen Anwendungsökosystem (GitHub Marketplace). GitLab zeichnet sich durch integriertes CI/CD und die Möglichkeit der vollständigen Self-hosted-Bereitstellung aus. Bitbucket ist eng in Jira und das Atlassian-Ökosystem integriert und in Unternehmensumgebungen beliebt.

Für die mobile Entwicklung wird die Plattformwahl oft durch die CI/CD-Fähigkeiten bestimmt: GitHub Actions unterstützt macOS-Runner für iOS-Builds, GitLab hat integrierte Runner für iOS/Android, Bitbucket lässt sich gut mit Firebase Test Lab integrieren. Unabhängig von der Plattform bleibt der PR-Prozess derselbe: Branch → Review → CI → Merge.