Pull Request in Git: was ist das und wie erstelle ich einen PR auf GitHub

Ein Pull Request (PR) ist ein Vorschlag, die Änderungen aus einem Branch in einen anderen zu übernehmen, und wird auf einer Plattform wie GitHub formuliert. Sie laden Ihren Branch auf den Server, öffnen einen PR, und das Team sieht sich den Diff an, kommentiert einzelne Zeilen, lässt automatische Prüfungen laufen und klickt erst danach auf die Schaltfläche zum Zusammenführen. In GitLab heißt derselbe Mechanismus Merge Request (MR). Kurz gesagt ist ein Pull Request der Kontrollpunkt zwischen „Ich habe den Code geschrieben“ und „Der Code ist in main angekommen“.

Git Pull Request: was ist das und woher kommt der Name

Der Name hat sich historisch entwickelt. Der Autor der Änderungen bittet den Besitzer des Repositorys, seinen Branch zu „pullen“, also zu übernehmen – daher Pull Request. GitLab hat sich für den Namen nach dem Ergebnis entschieden: Merge Request, also Zusammenführungsanfrage. Bitbucket und Azure DevOps verwenden den Begriff „Pull Request“. Im Kern ist es dasselbe: Quell-Branch, Ziel-Branch, Beschreibung, Diskussion, Prüfungen und ein Button zum Zusammenführen.

Wichtig ist: Der Pull Request ist kein Teil von Git. In Git selbst gibt es kein Objekt „PR“, Sie können es nicht durch einen Commit anlegen und nicht im Ordner .git finden. Es ist eine Entität der Plattform: GitHub speichert Beschreibung, Kommentare und den Status der Prüfungen bei sich, während Git nur für die Branches und Commits zuständig ist, die im PR enthalten sind.

Unter Entwicklern bedeutet die Abkürzung PR fast immer Pull Request: „Schick mir den PR“, „PR zum Review“, „PR gemergt“. Für GitLab sagt man MR.

Pull Request und git pull: der Unterschied

Die ähnlichen Begriffe werden ständig verwechselt. Der Befehl git pull lädt neue Commits vom Remote-Repository herunter und fügt sie direkt in Ihren aktuellen Branch ein – das ist eine lokale Operation im Terminal. Ein Pull Request ist eine Webseite auf GitHub mit dem Vorschlag, einen Branch in einen anderen zusammenzuführen.

Einen eigenen Befehl „git pull request“ gibt es in Git nicht. Es existiert das alte Hilfsprogramm git request-pull, das aber nur einen Text für eine E-Mail mit der Zusammenfassung der Änderungen erzeugt und mit PRs auf GitHub nichts zu tun hat.

Wozu Pull Requests dienen

Solange ein Projekt nur eine Person bearbeitet, kann man direkt in main committen. Sobald zwei oder mehr Personen im Repository arbeiten, werden direkte Pushes in den Hauptbranch zur Quelle kaputter Builds und verlorener Arbeit. Der Pull Request löst gleich mehrere Aufgaben:

• Code-Review – eine zweite Person sieht die Änderungen, bevor sie in main landen, und findet Fehler, die dem Autor entgangen sind;
• automatische Prüfungen – GitHub Actions oder ein anderes CI führt Tests und Linter für jeden PR aus, und ein roter Status verhindert das Zusammenführen von defektem Code;
• Entscheidungshistorie – nach einem Jahr erkennt man am PR nicht nur, was geändert wurde, sondern auch warum, mit der Diskussion;
• Beitrag zu fremden Projekten – in Open-Source-Projekten haben Sie keine Schreibrechte, und ein PR aus einem Fork ist der einzige Weg, eine Korrektur vorzuschlagen;
• Branch-Schutz – Schutzregeln für Branches auf GitHub können direkte Pushes in main verbieten und einen freigegebenen PR verlangen.

Pull Request auf GitHub aus einem Branch erstellen

Dies ist das Standardvorgehen für ein Team, in dem alle Schreibrechte auf das Repository haben. Die Arbeit findet in einem Feature-Branch statt, und main wird nur über einen PR geändert.

Schritt 1. Branch von aktuellem main erstellen

git switch main
git pull
git switch -c feature/login-form

Geben Sie dem Branch einen aussagekräftigen Namen: feature/…, fix/…, die Nummer der Aufgabe. Der Reviewer versteht sofort, worum es geht.

Schritt 2. Commits erstellen

git add src/login.js
git commit -m "Anmeldeformular hinzufügen"

Ein PR – eine Aufgabe. Ein kleiner PR mit 100 bis 300 Zeilen wird schnell und gründlich geprüft, bei 3000 Zeilen erteilt der Reviewer die Freigabe ungesehen.

Schritt 3. Branch auf den Server hochladen (git push für Pull Requests)

git push -u origin feature/login-form

Die Option -u verknüpft den lokalen Branch mit dem entfernten, danach genügt ein einfaches git push. In der Antwort schlägt GitHub den Link zur Erstellung des PR vor:

remote: Create a pull request for 'feature/login-form' on GitHub by visiting:
remote:      https://github.com/team/app/pull/new/feature/login-form

Schritt 4. PR in der Weboberfläche öffnen

Folgen Sie dem Link aus dem Terminal oder öffnen Sie das Repository auf GitHub – nach dem frischen Push erscheint dort ein Hinweis mit der Schaltfläche „Compare & pull request“. Ein anderer Weg führt über den Reiter „Pull requests“ und die Schaltfläche „New pull request“.

1. Prüfen Sie das Branch-Paar: base – wohin zusammengeführt wird (meist main), compare – Ihr Branch.
2. Schreiben Sie den Titel: was gemacht wurde, kurz und im Infinitiv oder als knappe Beschreibung.
3. Erklären Sie in der Beschreibung, warum die Änderung nötig ist, wie man sie prüft und was außerhalb des Umfangs bleibt. Gibt es im Repository eine PR-Vorlage, werden die Felder automatisch ausgefüllt.
4. Wählen Sie rechts die Reviewer (Reviewers), den Verantwortlichen (Assignees) und Labels, falls Ihr Team sie verwendet.
5. Klicken Sie auf „Create pull request“ oder wählen Sie einen Entwurf (dazu weiter unten).

PR aus dem Terminal erstellen: GitHub CLI

Wenn Sie nicht in den Browser wechseln möchten, gibt es das offizielle Werkzeug gh. Es ist kein Git-Befehl, sondern ein eigenes Programm von GitHub, für PRs aber sehr praktisch:

gh pr create --base main --title "Anmeldeformular hinzufügen" --body "Closes #42"
gh pr list
gh pr checkout 57
gh pr merge 57 --squash

Auf die Frage nach den Git-Befehlen für Pull Requests lautet die ehrliche Antwort: Git kann Branches, Commits und Push, den PR selbst erstellt man aber auf der Plattform – im Browser, mit gh oder über die API.

Pull Request in ein fremdes Repository über einen Fork

In offenen Projekten haben Sie keine Schreibrechte. Deshalb erstellen Sie zuerst einen Fork – eine eigene Kopie des Repositorys auf GitHub. Dort arbeiten Sie und schlagen die Änderungen dem Original vor.

1. Klicken Sie auf der Projektseite auf „Fork“ – es entsteht github.com/you/project.
2. Klonen Sie Ihren Fork und fügen Sie das Original als zweites Remote hinzu, meist upstream genannt.
3. Erstellen Sie einen Branch, machen Sie Commits und laden Sie den Branch in Ihren Fork hoch.
4. Öffnen Sie auf GitHub den PR: base repository – das Originalprojekt, head repository – Ihr Fork mit Ihrem Branch.

git clone git@github.com:you/project.git
cd project
git remote add upstream https://github.com/owner/project.git
git switch -c fix/typo-readme
git commit -am "Tippfehler in der README korrigieren"
git push -u origin fix/typo-readme

Werfen Sie vor der Arbeit einen Blick in die Datei CONTRIBUTING.md: Dort stehen meist die Regeln für Commit-Nachrichten, die Tests und die Frage, ob Sie zuerst ein Issue anlegen sollen. Halten Sie den Fork aktuell: git fetch upstream und git rebase upstream/main in Ihrem Branch, damit der PR nicht hinter dem Original zurückbleibt.

Merge Request in GitLab: was ist das und wie erstelle ich ihn

Der Merge Request der Git-Plattform GitLab ist ein vollständiges Gegenstück zum Pull Request. Die Bezeichnungen und Details der Oberfläche unterscheiden sich, der Ablauf ist aber derselbe: Branch, Push, Zusammenführungsanfrage, Review, Zusammenführen.

Einen MR können Sie auf mehrere Arten erstellen:

• über den Link, den GitLab nach dem git push eines neuen Branches im Terminal ausgibt;
• im Bereich Merge requests des Projekts mit der Schaltfläche „New merge request“, nachdem Sie Quell- und Ziel-Branch gewählt haben;
• direkt beim Push über die Push-Optionen von GitLab – ohne Browser.

git push -o merge_request.create -o merge_request.target=main origin feature/login-form

Die Terminologie von GitLab ist etwas anders: Die Freigabe heißt Approve, der Verantwortliche für das Zusammenführen ist der Assignee, und statt GitHub Actions arbeitet GitLab CI/CD mit der Datei .gitlab-ci.yml. Entwürfe von MRs gibt es ebenfalls, sie heißen Draft.

Review eines Pull Requests

Der Reviewer öffnet den Reiter „Files changed“ und sieht den Diff. Zu jeder Zeile kann er einen Kommentar hinterlassen oder einen fertigen Änderungsvorschlag (Suggestion) machen, den der Autor mit einem Klick übernimmt. Die Kommentare werden zu einem Review gesammelt und zusammen mit einem der folgenden Urteile abgeschickt:

• Comment – nur Anmerkungen ohne Entscheidung;
• Approve – die Änderungen sind freigegeben;
• Request changes – es sind Nacharbeiten nötig, das Zusammenführen ist nicht erwünscht.

Ein gutes Review prüft die Logik, die Lesbarkeit, die Tests und die Grenzfälle und streitet nicht über Geschmacksfragen – Formatierung überlässt man besser dem Linter im CI. Der Autor sollte auf jeden Kommentar antworten: umgesetzt, besprochen oder mit Begründung so belassen.

PR-Änderungen lokal prüfen (git checkout pull request)

Manchmal muss man den Code selbst ausführen. Liegt der Branch im selben Repository, genügen git fetch und git switch. Für einen PR aus einem Fork stellt GitHub spezielle Referenzen pull/<Nummer>/head bereit:

git fetch origin pull/57/head:pr-57
git switch pr-57

In GitLab heißen die entsprechenden Referenzen merge-requests/<Nummer>/head. Oder Sie verwenden einfach gh pr checkout 57, wenn die GitHub CLI installiert ist.

Pull Request nach Kommentaren aktualisieren

Der PR ist an den Branch gebunden, nicht an bestimmte Commits. Es genügt, neue Commits in denselben Branch zu legen und hochzuladen – der PR aktualisiert sich selbst, ein neuer Antrag ist nicht nötig.

git commit -am "Anmerkungen aus dem Review umsetzen"
git push

Git Rebase für Pull Requests: aktuellen main übernehmen

Während der PR im Review liegt, entwickelt sich main weiter. Meldet GitHub, dass der Branch veraltet ist oder Konflikte hat, aktualisieren Sie ihn. Die Variante mit Rebase ergibt eine lineare Historie:

git fetch origin
git rebase origin/main
# Konflikte lösen, git add, git rebase --continue
git push --force-with-lease

Nach einem Rebase ändern sich die Hashes der Commits, daher wird ein gewöhnlicher Push abgelehnt – man braucht einen erzwungenen. Verwenden Sie --force-with-lease: Es überschreibt den Branch nur dann nicht, wenn fremde Commits darin aufgetaucht sind. Arbeiten außer Ihnen noch andere im Branch, ist es sicherer, main mit git merge origin/main einzufügen – ohne Umschreiben der Historie.

Pull Request zusammenführen: merge, squash und rebase

Ist das Review freigegeben und die Prüfungen sind grün, kann der PR zusammengeführt werden. GitHub bietet drei Methoden an, der Administrator des Repositorys kann einige davon ausblenden.

Das Zusammenführen über die Oberfläche ist im Grunde dasselbe git merge, nur auf dem Server ausgeführt. Danach bietet GitHub an, den Branch zu löschen – stimmen Sie zu, er wird nicht mehr gebraucht. Lokal räumen Sie anschließend auf:

git switch main
git pull
git branch -d feature/login-form

Man kann einen PR auch von Hand im Terminal zusammenführen: den Branch lokal in main einfügen und pushen. GitHub erkennt, dass die Commits des Branches in der Basis angekommen sind, und markiert den PR selbst als gemergt. So gehen aber die Prüfungen und die Schutzregeln des Branches verloren; deshalb führt man in der Praxis über die Schaltfläche zusammen.

Auto-merge und Merge-Warteschlange

Dauern die Prüfungen lange, kann man das automatische Zusammenführen aktivieren: Der PR wird von allein gemergt, sobald alle Bedingungen erfüllt sind. In großen Repositorys verwendet man eine Merge-Warteschlange (merge queue), die jeden PR auf den bereits eingereihten Änderungen prüft, damit main nicht durch unverträgliche Änderungen bricht.

Entwürfe von Pull Requests (Draft)

Ein Entwurf ist ein PR, der noch nicht zum Review bereit ist. Er kann nicht zusammengeführt werden, und die Reviewer bekommen keine Aufforderung zur Prüfung. Entwürfe sind praktisch, um die Richtung früh zu zeigen, das CI laufen zu lassen oder eine Meinung zur Architektur einzuholen. Auf GitHub wählen Sie beim Erstellen des PR die Entwurf-Option im Aufklappmenü der Schaltfläche oder führen gh pr create --draft aus. Ist die Arbeit fertig, klicken Sie auf „Ready for review“. In GitLab kennzeichnet man einen Entwurf mit dem Präfix Draft: im Titel des MR.

Verknüpfung von Pull Requests mit Issues

Schreiben Sie in die Beschreibung des PR ein Schlüsselwort und die Nummer der Aufgabe, schließt GitHub das Issue nach dem Zusammenführen in den Standard-Branch automatisch:

Closes #42
Fixes #17
Resolves #8

Funktionieren die Wörter close, fix und resolve in verschiedenen Formen (closes, fixed, resolves). Die bloße Erwähnung #42 ohne Schlüsselwort erzeugt nur einen Link, schließt die Aufgabe aber nicht. In GitLab funktionieren Closes #42 und ähnliche Formulierungen genauso.

Kann man einen Pull Request oder Merge Request löschen?

Einen PR auf GitHub kann ein gewöhnlicher Teilnehmer nicht löschen – man kann ihn nur mit der Schaltfläche „Close pull request“ schließen. Ein geschlossener PR bleibt in der Historie und lässt sich wieder öffnen. Den Branch löschen Sie nach dem Schließen separat. Vollständig entfernen kann man einen PR nur über den GitHub-Support, etwa wenn Geheimnisse hineingeraten sind.

In GitLab kann den MR der Autor oder ein Teilnehmer mit entsprechenden Rechten schließen, löschen dürfen ihn der Projektinhaber oder ein Administrator. Ist ein Passwort oder Token in einen PR geraten, reicht das Schließen nicht: Widerrufen Sie das Geheimnis sofort, denn die Commits waren bereits auf dem Server.

Typische Fehler mit Pull Requests

• PR aus main. Sie haben in Ihrem main committet und den PR aus ihm geöffnet. Der nächste PR enthält dann auch die alten Änderungen. Arbeiten Sie immer in einem eigenen Branch.
• Falscher Basis-Branch. Der PR wurde in develop statt in main geöffnet oder umgekehrt. Die Basis lässt sich mit der Schaltfläche Edit neben dem Titel des PR ändern.
• Unnötige Dateien im Diff. Builds, node_modules, .env. Tragen Sie sie in die .gitignore ein und entfernen Sie sie mit git rm --cached aus dem Index.
• Riesiger PR. Teilen Sie die Aufgabe in mehrere aufeinanderfolgende PRs auf.
• Gewöhnlicher Push nach dem Rebase. Fehler rejected (non-fast-forward). Nötig ist git push --force-with-lease, nicht --force.
• Konflikte. Lösen Sie sie nicht blind im Web-Editor – holen Sie main lokal, lösen Sie den Konflikt und prüfen Sie die Tests.

Pull Request in Git Flow und anderen Prozessen

Der Pull Request passt in jeden Teamprozess. Im GitHub Flow ist alles einfach: Branch von main, PR, Review, Zusammenführen, Deployment. Im Git Flow werden PRs aus Feature-Branches nach develop geöffnet, und Release- und Hotfix-Branches laufen ebenfalls über einen PR nach main. In der Trunk-based-Entwicklung sind PRs kurz und leben Stunden statt Tage. Welcher Prozess auch gilt, die Regel ist dieselbe: Änderungen in gemeinsame Branches gelangen nur über einen Pull Request.

Fazit

Der Pull Request ist ein Mechanismus der Plattform und kein Git-Befehl: ein auf den Server gepushter Branch plus eine Seite mit Diskussion, Review und Prüfungen. Auf GitLab heißt er Merge Request, im Sprachgebrauch sagt man PR oder MR. Erstellen Sie PRs aus einem eigenen Branch, halten Sie sie klein, aktualisieren Sie sie per Push in denselben Branch und wählen Sie die Methode zum Zusammenführen passend zur Historie des Projekts. Forks, Feature-Branches und Pull Requests werden im Git-Kurs praktisch durchgearbeitet.