Ein Pull Request (kurz PR; bei GitLab Merge Request) ist eine Bitte, Änderungen aus einem Branch in einen anderen – meist main – zu übernehmen. Er ist das zentrale Werkzeug für Zusammenarbeit mit Git: Änderungen werden nicht direkt geschrieben, sondern vorgeschlagen, geprüft und dann zusammengeführt.
Der typische Ablauf
- Branch anlegen:
git switch -c feature/login-validation - Änderungen committen und pushen:
git push -u origin feature/login-validation - PR eröffnen – mit Titel, Beschreibung und Bezug zum Ticket.
- Review: Kolleginnen und Kollegen lesen den Diff, kommentieren und fordern ggf. Änderungen an.
- Automatische Prüfungen: CI lässt Tests, Linter und Sicherheitsscans laufen (CI/CD).
- Merge nach Freigabe und grüner Pipeline.
Die drei Merge-Strategien
- Merge Commit: Die Historie des Branches bleibt vollständig erhalten, es entsteht ein zusätzlicher Zusammenführung-Commit.
- Squash: Alle Commits des Branches werden zu einem einzigen zusammengefasst – ergibt eine lineare, aufgeräumte Historie.
- Rebase: Die Commits werden auf den aktuellen Stand des Zielbranches umgeschrieben, ohne Merge-Commit.
Für kleine Feature-Branches ist Squash in vielen Teams die pragmatischste Wahl.
Was einen guten PR ausmacht
- Klein halten: Ein PR, der 40 Dateien und 2000 Zeilen umfasst, wird nicht ernsthaft gelesen.
- Beschreibung mit Kontext: Warum diese Änderung, was ist getestet, was ist bewusst nicht enthalten?
- Aussagekräftige Commits: siehe Commit.
- Draft-PR für frühe Rückmeldung, bevor die Arbeit fertig ist.
- Review-Kultur: Kritik am Code, nicht an der Person; begründen statt anordnen.