Was ist ein Pull Request in der Softwareentwicklung?

Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · Richtet Branch Protection, CI-Prüfungen und Code-Review-Workflows für Produktteams in den USA und der EU ein

Was ist ein Pull Request in der Softwareentwicklung? Es ist eine formelle Anfrage, eine Reihe von Codeänderungen aus einem Branch in einen anderen zu übernehmen — meist aus einem kurzlebigen Feature-Branch in main —, nachdem andere Entwickler sie geprüft haben. Entwickler kürzen ihn mit „PR“ ab, und in den meisten Teams gelangt nichts ohne ihn in die Produktion: Im PR liegen Diff, Begründung, Testergebnisse und die Review-Diskussion beisammen.

Teams, die Software-Product-Engineering-Services im großen Maßstab betreiben, behandeln den Pull Request als das eine Tor, das jede Änderung passieren muss — Review, Tests und Sicherheitsprüfungen finden dort statt, nicht nach dem Release. Damit ist der PR einer der günstigsten Orte, um einen Fehler zu finden, und einer der teuersten, um Zeit zu verlieren, wenn Reviews stocken.

Die Größenordnung ist enorm. Laut GitHubs Octoverse-Report 2025 haben Entwickler zwischen September 2024 und August 2025 durchschnittlich 43,2 Millionen Pull Requests pro Monat gemergt, 23 % mehr als im Vorjahr, bei knapp einer Milliarde gepushter Commits. Im Folgenden finden Sie die Definition des Pull Requests, den kompletten PR-Lebenszyklus, Schritt-für-Schritt-Anleitungen zum Erstellen und Prüfen, die drei Merge-Methoden, gängige Workflows, Benchmarks 2026 und praktische Regeln für die wachsende Welle KI-generierter PRs.

Was ist ein PR in der Softwareentwicklung?

Ein PR ist in der Softwareentwicklung ein Pull Request: ein Vorschlag, einen Branch mit Codeänderungen in einen anderen Branch zu mergen, der vor dem Merge von Teammitgliedern geprüft und freigegeben wird. Die Pull-Request-Definition in einem Satz: ein prüfbares, diskutierbares und testbares Änderungspaket, das die Verantwortlichen eines Ziel-Branches um Übernahme bittet.

Ein Pull Request vergleicht immer zwei Branches. Der Head-Branch (auch Quell- oder Compare-Branch) enthält die neue Arbeit; der Base-Branch (das Ziel) ist der Ort, an dem sie landen soll, typischerweise main oder develop. Die Plattform stellt den Unterschied als Diff dar — hinzugefügte Zeilen grün, entfernte rot — und Reviewer können jede Zeile kommentieren.

An einem typischen PR sind drei Rollen beteiligt. Der Autor schreibt den Code, öffnet die Anfrage und reagiert auf Feedback. Ein oder mehrere Reviewer lesen den Diff, stellen Fragen, schlagen Änderungen vor und geben frei. Ein Maintainer oder der Autor (sobald die Freigaben vorliegen) führt den Merge aus. Pull Requests leben auf der Git-Hosting-Plattform: GitHub, GitLab, Bitbucket und Azure DevOps setzen dieselbe Idee um, wie IBMs Überblick zu Pull Requests festhält, auch wenn die Buttons unterschiedlich heißen.

Was bedeutet PR in der Softwareentwicklung?

In der Softwareentwicklung bedeutet PR Pull Request — nicht Public Relations. Der Name stammt aus dem ursprünglichen Open-Source-Modell: Ein Beitragender ohne Schreibrechte pushte Änderungen in seine eigene Kopie und bat den Maintainer, sie hineinzuziehen (to pull). Heute pusht der Autor oft ins selbe Repository, doch der Name blieb. Entwickler verwenden „PR“ als Substantiv („einen PR öffnen“), als Workflow-Phase („das liegt im PR“) und als Arbeitseinheit („heute drei PRs gemergt“).

Pull Request vs. Merge Request

Pull Request und Merge Request sind dasselbe unter zwei Namen: GitHub, Bitbucket und Azure DevOps sagen „Pull Request“, GitLab sagt „Merge Request“ (MR), weil die abschließende Aktion ein Merge ist. Die GitLab-Dokumentation beschreibt Merge Requests als den Ort, an dem Codeänderungen vorgeschlagen, geprüft und gemergt werden — genau die Aufgabe, die anderswo ein PR erfüllt.

Wie funktioniert ein Pull Request?

Ein Pull Request funktioniert als kurze Schleife: Sie zweigen von main ab, committen Ihre Änderungen, öffnen einen PR, lassen Automatisierung und Reviewer prüfen, beheben die Funde und mergen nach der Freigabe. Jeder PR in der Softwareentwicklung folgt grob denselben sieben Schritten:

1. Branch anlegen. Starten Sie einen Feature-Branch vom aktuellen main, damit Ihre Arbeit von der aller anderen getrennt ist.
2. Änderungen committen. Machen Sie kleine, logisch gruppierte Commits mit klaren Nachrichten.
3. Branch pushen. Laden Sie ihn in das gemeinsame Remote-Repository hoch (GitHub, GitLab, Bitbucket oder Azure DevOps).
4. Pull Request öffnen. Wählen Sie den Base-Branch, schreiben Sie Titel und Beschreibung, verlinken Sie das Ticket und fordern Sie Reviewer an.
5. Automatisierte Prüfungen laufen lassen. Die CI/CD-Pipeline baut den Code und führt Unit-Tests, Linter, Typprüfungen und Sicherheitsscans aus; die Ergebnisse erscheinen als Status-Checks im PR.
6. Prüfen und überarbeiten. Reviewer kommentieren und fordern Änderungen an; der Autor pusht neue Commits auf denselben Branch, und der PR aktualisiert sich automatisch.
7. Freigeben und mergen. Sind Pflicht-Freigaben und Checks grün, wird der PR in den Base-Branch gemergt, der Feature-Branch gelöscht und die Änderung fließt weiter ins Deployment.

Entscheidend ist: Der PR ist ein lebendes Objekt. Jeder neue Commit auf dem Head-Branch aktualisiert den Diff, startet die Prüfungen neu und markiert ältere Kommentare als veraltet, sodass die Diskussion immer den aktuellen Code widerspiegelt. Der Base-Branch bleibt unberührt, bis jemand auf Merge klickt.

Anatomie eines guten Pull Requests

Ein guter Pull Request ist klein, fokussiert und selbsterklärend: Ein Reviewer soll verstehen, was sich geändert hat, warum und wie es sich überprüfen lässt, ohne den Autor fragen zu müssen. In unseren Teams wird ein PR, der diese sieben Punkte erfüllt, meist noch am selben Tag geprüft:

• Ein konkreter Titel. „Retry mit Backoff im Payment-Webhook-Handler ergänzen“ schlägt „Bug fixen“.
• Eine Beschreibung, die Was, Warum und Wie-testen beantwortet. Zwei, drei kurze Absätze oder ein ausgefülltes PR-Template.
• Ein verlinktes Ticket. Die Issue- oder Story-ID verbindet den Code mit der fachlichen Anforderung und erhält den Audit-Trail.
• Ein kleiner Diff. Ein Zweck pro PR; Refactoring und Feature-Arbeit gehören in getrennte PRs.
• Visueller Nachweis bei UI-Änderungen. Vorher-nachher-Screenshots oder eine kurze Bildschirmaufnahme.
• Eine abgehakte Checkliste. Tests ergänzt, Doku aktualisiert, Migrationen umkehrbar, Feature Flag gesetzt — was Ihr PR-Template eben verlangt.
• Die richtigen Reviewer und Labels. Eine CODEOWNERS-Datei fordert das zuständige Team automatisch an; Labels wie security oder breaking-change lenken die Aufmerksamkeit.

Einen Pull Request erstellen: Schritt für Schritt

Um einen Pull Request zu erstellen, pushen Sie einen Feature-Branch ins gemeinsame Repository und öffnen einen PR gegen den Base-Branch, entweder in der Weboberfläche oder auf der Kommandozeile. So gehen wir auf GitHub vor; GitLab, Bitbucket und Azure DevOps unterscheiden sich nur in den Button-Namen:

1. Lokalen main aktualisieren. Führen Sie git checkout main und git pull aus, damit Sie vom neuesten Stand abzweigen.
2. Feature-Branch anlegen. git checkout -b feature/payment-retry — mit sprechendem, ticketbezogenem Namen.
3. Ändern und committen. git add ., dann git commit -m "Add exponential backoff to payment webhook". Halten Sie Commits klein und aussagekräftig.
4. Branch pushen. git push -u origin feature/payment-retry lädt ihn hoch und setzt den Upstream.
5. PR öffnen. Klicken Sie in der Weboberfläche auf „Compare & pull request“ oder führen Sie mit der GitHub CLI gh pr create --base main --fill aus.
6. Beschreibung und Reviewer ergänzen. Füllen Sie das Template aus, verlinken Sie das Ticket, fordern Sie Reviewer an oder lassen Sie CODEOWNERS sie zuweisen.
7. Draft oder bereit wählen. Öffnen Sie ihn als Draft, wenn Sie frühes Feedback oder einen CI-Lauf vor Fertigstellung wollen; markieren Sie ihn als „Ready for review“, wenn er fertig ist.

Draft Pull Requests lohnen sich öfter, als man denkt. Sie signalisieren „schaut auf die Richtung, nicht auf Details“, lassen CI den Branch prüfen, während Sie weiterarbeiten, und können nicht versehentlich gemergt werden.

Wie Sie einen Pull Request prüfen

Um einen Pull Request zu prüfen, lesen Sie zuerst die Beschreibung, dann den Diff, und kontrollieren fünf Dinge: Korrektheit, Tests, Lesbarkeit, Sicherheit und Performance. Am Ende steht eines von drei Urteilen — kommentieren, freigeben oder Änderungen anfordern. Eine praktische Reviewer-Checkliste:

• Korrektheit. Tut der Code, was Beschreibung und Ticket sagen, einschließlich Randfällen und Fehlerpfaden?
• Tests. Gibt es Tests für das neue Verhalten, und würden sie fehlschlagen, wenn die Änderung zurückgenommen würde?
• Lesbarkeit und Design. Sind Namen klar, liegt die Logik in der richtigen Schicht, versteht ein neues Teammitglied den Code?
• Sicherheit. Eingabevalidierung, Berechtigungsprüfungen, Secrets, Injection-Risiken, neue Abhängigkeiten.
• Performance und Betrieb. N+1-Abfragen, unbegrenzte Schleifen, fehlende Indizes, Logging und Metriken für den neuen Pfad.

Kennzeichnen Sie das Gewicht jedes Kommentars. Ein blockierender Kommentar muss vor dem Merge behoben werden; ein Nit („nit: in retryCount umbenennen“) ist optionaler Feinschliff. Plattformen unterstützen außerdem Suggested Changes: Der Reviewer schreibt die exakte Ersatzzeile, der Autor übernimmt sie mit einem Klick — das spart bei kleinen Korrekturen eine ganze Runde.

Tempo zählt so viel wie Gründlichkeit. In „Modern Code Review: A Case Study at Google“ (Sadowski et al., ICSE-SEIP 2018), basierend auf rund neun Millionen geprüften Änderungen, umfasste die mediane Änderung nur 24 Zeilen, mehr als 35 % der Änderungen betrafen eine einzige Datei, das mediane Warten auf erstes Feedback lag bei kleinen Änderungen unter einer Stunde (bei sehr großen bei etwa fünf Stunden) und die mediane Gesamt-Review-Latenz unter vier Stunden. Kleine Änderungen und schnelles erstes Feedback gehören zusammen.

Einen Pull Request mergen: Merge Commit vs. Squash vs. Rebase

Einen Pull Request zu mergen heißt, seine Commits auf den Base-Branch anzuwenden, und GitHub bietet dafür drei Methoden, die sich nur darin unterscheiden, wie die Historie danach aussieht. Laut GitHub Docs („About pull request merges“) bewahrt ein Merge Commit alle Commits und fügt einen expliziten Merge-Punkt hinzu, Squash and Merge fasst alle Commits zu einem einzigen zusammen, und Rebase and Merge spielt die Commits einzeln ab und hält die Historie linear.

Bevor einer dieser Buttons überhaupt funktioniert, entscheiden Branch-Protection-Regeln, ob gemergt werden darf: Pflicht-Freigaben, Pflicht-Status-Checks, aufgelöste Diskussionen und optional eine Merge Queue, die jeden PR gegen den neuesten Base-Branch testet, bevor sie ihn mergt — so können zwei einzeln grüne PRs main nicht gemeinsam kaputtmachen.

Ein Merge-Konflikt entsteht, wenn im Base-Branch dieselben Zeilen geändert wurden, die Ihr PR berührt. Lösen Sie ihn, indem Sie Ihren Branch aktualisieren (git fetch, dann git rebase origin/main oder git merge origin/main), die konfliktbehafteten Stellen auflösen, die Tests erneut laufen lassen und pushen. Kleine, kurzlebige PRs geraten selten in Konflikt; eine Woche alte fast immer.

Pull-Request-Workflows, die Teams nutzen

Pull-Request-Workflows legen fest, wie Branches entstehen, wie lange sie leben und wohin sie gemergt werden. Die meisten Teams nutzen einen von fünf; IBMs Pull-Request-Leitfaden nennt die ersten vier als die gängigen Muster.

Feature-Branch-Workflow

Im Feature-Branch-Workflow bekommt jede Änderung einen eigenen Branch von main und kehrt über einen Pull Request zurück. In den meisten Produktteams ist das der Standard: leicht zu erklären, einfach mit Branch-Regeln abzusichern und von jeder Plattform gut unterstützt.

Forking-Workflow

Im Forking-Workflow kopieren Beitragende das gesamte Repository in ihr eigenes Konto, pushen in den Fork und öffnen einen Pull Request zurück zum Originalprojekt. Open-Source-Projekte setzen darauf, weil externe Beitragende nie Schreibrechte im Haupt-Repository brauchen.

Git-flow

Git-flow nutzt langlebige Branches main und develop sowie Feature-, Release- und Hotfix-Branches, die jeweils per PR gemergt werden. Das passt zu Produkten mit geplanten, versionierten Releases — Mobile-Apps, On-Premise-Software —, erzeugt aber Overhead für Teams, die kontinuierlich deployen.

Trunk-Based Development mit kurzlebigen PRs

Beim Trunk-Based Development mergen Entwickler mindestens täglich kleine PRs in main, und unfertige Features bleiben hinter Feature Flags verborgen. Branches leben Stunden statt Wochen, was Konflikte selten macht und Continuous Delivery unterstützt.

Gestapelte Pull Requests (Stacked PRs)

Gestapelte Pull Requests teilen ein großes Feature in eine Kette kleiner, voneinander abhängiger PRs, die jeweils auf dem vorherigen aufbauen. Reviewer bekommen kleine Diffs, der Autor arbeitet weiter, ohne auf jedes Review zu warten, und der Stapel wird der Reihe nach gemergt.

Warum Pull Requests wichtig sind: Nutzen für Codequalität und Teams

Pull Requests sind wichtig, weil sie einen einzigen, dokumentierten Kontrollpunkt zwischen die Idee eines Entwicklers und die Produktion setzen. Die wichtigsten Vorteile:

• Qualitätstor. Fehler, fehlende Tests und Designprobleme werden gefunden, solange die Änderung noch günstig zu korrigieren ist.
• Wissensaustausch. Mindestens zwei Personen verstehen jede Änderung — das senkt das Bus-Faktor-Risiko.
• Nachvollziehbarkeit und Audit-Trail. Wer was geändert, wer es freigegeben hat und warum, ist dokumentiert — genau die Nachweise, die Auditoren für das Change Management nach SOC 2 und ISO 27001 erwarten.
• Schnelleres Onboarding. Neue Entwickler lernen Codebasis und Teamkonventionen, indem sie PRs lesen und prüfen.
• Shift-left-Sicherheit. Abhängigkeitsprüfungen, Secret-Scanning und statische Analyse laufen bei jedem PR, nicht einmal vor dem Release.
• CI-Integration. Der PR ist der natürliche Auslöser für Builds, Tests und Preview-Umgebungen, und diese Prüfungen bilden den Kern der Qualitätssicherung in der Softwareentwicklung.

Pull-Request-Metriken und Benchmarks 2026

Fünf Pull-Request-Metriken zeigen, ob Ihr Review-Prozess die Auslieferung beschleunigt oder bremst: Pickup-Zeit, Review-Zeit, Cycle Time, PR-Größe und Akzeptanzrate (Merge-Rate). Sie hängen direkt mit Softwareentwicklungs-KPIs und DORA-Metriken wie der Lead Time for Changes zusammen.

• Pickup-Zeit — vom Öffnen des PR (oder der Markierung als bereit) bis zur ersten Review-Aktivität.
• Review-Zeit — vom ersten Review bis zur Freigabe oder zum Merge.
• Cycle Time — vom ersten Commit bis zum Merge oder Deployment; Pickup und Review sind oft ihre größten Anteile.
• PR-Größe — geänderte Zeilen; der stärkste Prädiktor dafür, wie lange ein Review dauert.
• Akzeptanzrate — der Anteil geöffneter PRs, die innerhalb eines festen Zeitfensters gemergt werden.

Der LinearB 2026 Software Engineering Benchmarks Report, basierend auf 8,1 Millionen Pull Requests von 4.800 Teams und 163.820 Beitragenden in 42 Ländern, schlüsselt diese Metriken danach auf, wie der Code entstanden ist. Die Werte sind 75.-Perzentil-Werte; die Akzeptanz ist die Merge-Rate innerhalb von 30 Tagen:

Nutzen Sie diese Zahlen als Referenz, nicht als Ziel. Verfolgen Sie Ihre eigenen Mediane wöchentlich, beobachten Sie den Trend und schauen Sie zuerst auf die Pickup-Zeit: Sie ist meist die am leichtesten zu beseitigende Verzögerung, weil sie reines Warten ist.

KI-generierte Pull Requests 2026: Was sich für Reviewer ändert

KI-generierte Pull Requests sind größer, warten länger auf ein Review und werden deutlich seltener gemergt als von Menschen geschriebene — sie brauchen also strengere Regeln, keine lockereren. Die LinearB-Benchmarks 2026 zeigen KI-unterstützte PRs mit 408 Zeilen gegenüber 157 bei manuellen (75. Perzentil), Pickup-Zeiten von 8,3 Stunden für KI-unterstützte und 17,6 Stunden für agentische PRs gegenüber 3,4 Stunden für manuelle sowie eine 30-Tage-Akzeptanzrate von 32,7 % für KI-PRs gegenüber 84,4 % für manuelle. Selbst in der Elite-Klasse werden manuelle PRs zu über 95 % akzeptiert, KI-PRs zu knapp über 71 %.

Das Muster ist leicht erklärt: Reviewer zögern, einen großen Diff aufzugreifen, den niemand im Team wirklich geschrieben hat, und lehnen ihn ab, wenn die Absicht unklar ist. Diese Gegenmaßnahmen setzen wir in unseren Teams ein:

1. Größe deckeln. Für KI- und menschliche PRs gilt dieselbe Größenrichtlinie; ein Agent, der 1.000 Zeilen erzeugt, sollte seine Arbeit in einen Stapel aufteilen.
2. Tests für jeden KI-PR verlangen. Kein neues Verhalten ohne Tests, die mit dem alten Code fehlschlagen.
3. Einen menschlichen Verantwortlichen benennen. Jeder KI-generierte PR hat einen namentlich benannten Entwickler, der Review-Fragen beantwortet und für den Merge geradesteht.
4. KI-Review-Bots als ersten Durchgang nutzen. Automatische Reviewer finden Stilprobleme, offensichtliche Fehler und fehlende Null-Checks gut, die finale Freigabe bleibt aber bei einem Menschen, der das System versteht.
5. Absicht beschreiben, nicht nur Ergebnis. Die PR-Beschreibung muss Problem und gewählten Ansatz erklären, egal ob ein Mensch oder ein Agent den Code geschrieben hat.

Best Practices für Pull Requests

Die wirksamste Best Practice für Pull Requests lautet: PRs klein und fokussiert halten; die meisten anderen Praktiken dienen dazu, kleine PRs schnell prüfbar und mergebar zu machen. Sieben Regeln, die sich über Teams und Stacks hinweg bewähren und die breiteren Best Practices der Softwareentwicklung ergänzen:

1. PRs klein halten. Eine Teamrichtlinie von etwa 200–400 geänderten Zeilen funktioniert gut; Googles mediane Änderung von 24 Zeilen (2018) und LinearBs 157 Zeilen im 75. Perzentil für manuelle PRs (2026) zeigen, wie klein gesunde PRs meist sind.
2. Ein Zweck pro PR. Mischen Sie Refactoring, Dependency-Update und Feature nicht in einem Diff.
3. Eine klare Beschreibung schreiben. Nutzen Sie ein PR-Template mit Was, Warum, Wie-testen und Risiken.
4. Drafts früh öffnen. Holen Sie Feedback zur Richtung, bevor Sie in Feinschliff investieren.
5. Jede mögliche Prüfung automatisieren. Formatierung, Linting, Tests, Typprüfungen und Sicherheitsscans sollten bei jedem Push laufen, damit sich Reviewer auf Logik und Design konzentrieren.
6. Ein Review-SLA festlegen. Zum Beispiel erste Antwort innerhalb von vier Arbeitsstunden und Entscheidung innerhalb eines Werktags.
7. Alle Diskussionen vor dem Merge auflösen. Aktivieren Sie die Regel in der Branch Protection, damit nichts mit offenen Fragen gemergt wird.

Häufige Pull-Request-Probleme und wie Sie sie lösen

Die meisten Pull-Request-Probleme entstehen durch Größe und Warten: Große PRs warten länger, geraten häufiger in Konflikte und bekommen schwächere Reviews. Fünf Probleme, die wir am häufigsten sehen, jeweils mit Lösung:

• Übergroße PRs. Reviewer überfliegen oder verschieben sie. Lösung: nach Schichten aufteilen oder gestapelte PRs nutzen und eine Größenwarnung in CI einbauen.
• Review-Engpässe. Ein Senior-Entwickler prüft alles. Lösung: Verantwortung per CODEOWNERS verteilen, Reviewer rotieren und die Pickup-Zeit messen.
• Merge-Konflikte. Langlebige Branches driften von main weg. Lösung: täglich mergen, oft rebasen und Feature Flags statt langer Branches nutzen.
• Durchgewunkene Freigaben. „LGTM“ nach Sekunden bei einem 900-Zeilen-Diff. Lösung: kleinere PRs, eine Review-Checkliste und Pflicht-Freigabe durch einen Code Owner.
• Verwaiste PRs. Aufgegebene Branches verstopfen die Warteschlange. Lösung: PRs nach sieben Tagen Inaktivität automatisch labeln und in einer wöchentlichen Triage schließen oder wiederbeleben.

FAQ

Veröffentlicht am 7. Oktober 2026. Quellen: IBM Think, „What is a pull request?“; GitHub Docs, „About pull request merges“; GitHub Octoverse 2025; LinearB 2026 Software Engineering Benchmarks Report; Sadowski et al., „Modern Code Review: A Case Study at Google“, ICSE-SEIP 2018; GitLab Docs, „Merge requests“. Die Benchmarks sind Referenzwerte; gleichen Sie sie mit den Daten Ihres eigenen Teams ab.