Merge Request (MR): Was es ist, wie man es erstellt und der Review-Prozess

Was ist ein Merge Request (MR)?

Merge Request (MR) — eine Anfrage zur Integration von Änderungen von einem Git-Branch in einen anderen, die den Prozess des Code-Reviews und automatisierter Prüfungen einleitet. Im Gegensatz zum direkten Zusammenführen über die Konsole schafft MR ein formelles Verfahren: Der Entwickler beschreibt die Änderungen, weist Reviewer zu, startet CI/CD und erhält Feedback, bevor die Änderungen übernommen werden. Dies ist ein Schlüsselelement von GitLab, aber der äquivalente Mechanismus in GitHub heißt Pull Request (PR).

Laut GitLab Documentation, 2026 werden in GitLab jährlich über 80 Millionen Merge Requests erstellt. Jeder MR enthält vier Hauptkomponenten: eine Beschreibung mit Kontext der Änderungen, eine Liste der Commits, den Code-Unterschied (Diff) und eine Diskussion (Diskussionsthread). Ohne eines dieser Elemente gilt der MR als unvollständig.

Merge Request (MR) löst drei Aufgaben: Er verhindert direkte Änderungen an geschützten Branches (main, develop), bietet Qualitätskontrolle durch Reviews und bewahrt den Diskussionsverlauf für zukünftige Entwickler. In GitLab wird der MR-Status in der Oberfläche mit Farbindikatoren angezeigt: Grau für Draft, Orange für ausstehend, Grün für Approved, Lila für Merged und Rot für Closed.

Terminologie: MR, PR und CR

Auf verschiedenen Git-Plattformen wird Merge Request unterschiedlich genannt. GitLab verwendet „Merge Request“ (MR), GitHub verwendet „Pull Request“ (PR). Die Analogie ist Change Request (CR) in Gerrit. Alle drei bezeichnen denselben Prozess: Eine Anfrage zur Integration von Änderungen durch Code-Review. Die Wahl des Begriffs hängt nur von der im Projekt verwendeten Plattform ab.

# Einen Branch mit Änderungen erstellen
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# Sie können einen MR über die GitLab/GitHub-Benutzeroberfläche oder die CLI erstellen:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: Der Unterschied zwischen GitLab und GitHub

Merge Request in GitLab und Pull Request in GitHub sind funktional identische Mechanismen mit unterschiedlichen Namen. Der Unterschied ist historisch bedingt: GitLab positionierte sich ursprünglich als Self-Hosted-Alternative zu GitHub und wählte den Begriff „Merge Request“ für den Zusammenführungsprozess. GitHub, das früher gestartet wurde, verwendete „Pull Request“ — eine Anfrage, Änderungen in den Hauptbranch zu “ziehen“ (pull).

Laut GitHub Docs, 2024 unterstützen beide Tools denselben Funktionsumfang: Markdown-Beschreibung, Reviewer-Zuweisung, Kommentare zu bestimmten Codezeilen, Prüfstatus und automatisches Zusammenführen bei erfüllten Bedingungen. Die Unterschiede betreffen die Oberfläche und zusätzliche Funktionen.

Wie man einen Merge Request erstellt: Schritt-für-Schritt-Anleitung

Die Erstellung eines Merge Request (MR) beginnt mit der Veröffentlichung eines Branches mit Änderungen im entfernten Repository. Nach dem Push zu GitLab oder GitHub erscheint in der Oberfläche ein Button „Create Merge Request“ oder „Compare & Pull Request“. Der Entwickler füllt die Beschreibung aus, gibt den Zielbranch an (normalerweise develop oder main), weist Reviewer zu und fügt Labels hinzu.

Laut GitLab Documentation, 2025 enthält ein Standard-MR einen Titel mit bis zu 72 Zeichen, eine Beschreibung mit Vorlage und einen Link zum Issue. Die Beschreibung sollte die Fragen beantworten: Was wurde getan, warum, wie wurde getestet. GitLab unterstützt das automatische Schließen von Issues beim Merge durch die Schlüsselwörter Closes, Fixes, Resolves.

# Beispiel für die Vorlage .gitlab/merge_request_templates/default.md
## What does this MR do?

[Kurzbeschreibung der Änderungen: was und warum]

## How to test

1. Ausführen ./gradlew test
2. Überprüfen LoginActivity mit dem Testtoken
3. Sicherstellen, dass keine Regression in AuthManager

## Related issues

Closes #142

MR-Lebenszyklus: Von Draft bis Merged

Merge Request (MR) durchläuft in GitLab fünf Status. Der erste ist Draft (Entwurf), gekennzeichnet durch das Präfix „Draft:“ im Titel, das das Zusammenführen blockiert. Wenn bereit, entfernt der Entwickler den Draft, und der MR wechselt in den Status Opened — das Code-Review beginnt und die CI/CD-Pipeline startet.

Laut GitLab Docs, 2024 prüfen Reviewer im Status Opened den Diff, hinterlassen Kommentare und fordern Änderungen über Resolve Threads an. Wenn alle Threads aufgelöst sind und CI/CD erfolgreich ist, setzt der verantwortliche Entwickler Approve. Danach kann der MR über den Merge-Button zusammengeführt oder auf automatisches Zusammenführen (Auto-merge) gewartet werden.

GitLab unterstützt drei Optionen für den Endstatus: Merged (erfolgreich zusammengeführt), Closed (ohne Zusammenführung geschlossen, z. B. bei Aufgabe einer Funktion) und Reopened (Wiederöffnung nach Schließung). Jeder Status wird für Prüfzwecke im MR-Aktivitätszeitplan protokolliert.

Automatische Status und Auslöser

GitLab aktualisiert den Status des Merge Request automatisch bei Ereignissen: Beim Push neuer Commits werden Approvals zurückgesetzt, bei erfolgreicher CI-Pipeline wird der Status zu Pipeline passed, bei Fehlschlag — Pipeline failed (Merge wird blockiert). Auto-merge kann konfiguriert werden: Der MR wird nach erfolgreichem CI und Erhalt aller erforderlichen Genehmigungen automatisch zusammengeführt.

• Draft — Entwurf, CI läuft, aber Merge blockiert
• Opened — bereit für Review, Reviewer zugewiesen, Pipeline aktiv
• Approved — erforderliche Anzahl von Genehmigungen erhalten
• Merged — Änderungen in Zielbranch eingefügt
• Closed — ohne Zusammenführung geschlossen

Code-Review-Regeln im Merge Request

Code-Review im Merge Request (MR) ist in den meisten kommerziellen Projekten eine obligatorische Phase. Laut einer Studie von SmartBear, 2023 reduziert Code-Review mit MR die Anzahl der Fehler um 30–60% und beschleunigt die Einarbeitung neuer Entwickler. Die Grundregel ist, dass jeder MR von mindestens einem, vorzugsweise zwei Entwicklern überprüft wird, die nicht am Schreiben des Codes beteiligt waren.

MR-Überprüfung umfasst fünf Kriterien: logische Korrektheit, Einhaltung des Codestils, Testabdeckung, Sicherheit und Leistung. In GitLab können Required Approvals konfiguriert werden — die erforderliche Anzahl von Genehmigungen vor dem Merge, z. B. 2 Genehmigungen für main und 1 für develop.

Diskussion im MR wird in Threads geführt — Kommentaren zu bestimmten Codezeilen. Jeder Thread muss vor dem Merge aufgelöst werden. Zur Beschleunigung von Reviews wird empfohlen, die MR-Größe zu begrenzen: 200–400 Änderungszeilen. Laut Google Research (2022) werden MRs mit mehr als 400 Zeilen 30% weniger effektiv überprüft.

CI/CD-Pipeline im Merge Request

Beim Erstellen eines Merge Request (MR) wird die CI/CD-Pipeline automatisch gestartet. In GitLab geschieht dies über die Datei .gitlab-ci.yml, in GitHub über den GitHub Actions-Workflow. Die Pipeline umfasst Projekt-Build, Unit-Tests, Linter, statische Analyse (SAST) und Codeabdeckungsprüfung.

Laut GitLab Blog, 2024 wird der Pipelinestatus direkt im MR angezeigt: grünes Häkchen (passed), rotes Kreuz (failed) oder gelber Kreis (running). Wenn die Pipeline fehlschlägt, blockiert GitLab den Merge-Button bis zur Behebung. In den Einstellungen kann „Merge when pipeline succeeds“ aktiviert werden — automatisches Zusammenführen nach erfolgreicher Pipeline.

# .gitlab-ci.yml — Beispiel für ein Android-Projekt
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

build:
  stage: build
  script:
    - ./gradlew assembleDebug
  only:
    - merge_requests

Merge-Methoden: Squash, Merge Commit, Fast-Forward

GitLab und GitHub bieten drei Merge-Methoden für Merge Request an. Die Wahl hängt von der Teamrichtlinie und der gewünschten Historiensauberkeit ab. Merge Commit erstellt einen separaten Merge-Commit und bewahrt die gesamte Historie des Feature-Branches. Squash fasst alle Branch-Commits in einem einzigen Commit auf dem Zielbranch zusammen. Fast-Forward wendet Commits linear ohne Merge-Commit an.

Laut GitLab Docs, 2025 wird Squash für Projekte mit hoher Commit-Dichte bevorzugt (20+ Commits in einem Feature-Branch). Fast-Forward ist für Trunk-Based Development obligatorisch. Merge Commit wird in Git Flow verwendet, um die Branching-Semantik zu bewahren.

• Merge Commit — bewahrt Historie, erstellt Merge-Commit, geeignet für Git Flow
• Squash — fasst alle Commits zu einem zusammen, saubere Historie, verliert Zwischencommits
• Fast-Forward — lineare Historie ohne Merge-Commit, obligatorisch in TBD

Best Practices: Wie man einen guten MR schreibt

Ein qualitativ hochwertiger Merge Request (MR) reduziert die Review-Zeit und die Anzahl der Fehler. Die erste Regel ist, dass ein MR eine Aufgabe löst. Wenn Änderungen mehrere nicht zusammenhängende Funktionen betreffen, sollten sie in separate MRs aufgeteilt werden. Zweitens sollte der MR-Titel informativ sein: „Add OAuth2 authentication with Google provider“ statt „Fix stuff“ oder „Update code“.

Laut Google Engineering Practices, 2024 enthält ein guter MR eine Kontextbeschreibung: Warum die Änderungen notwendig sind, wie sie getestet wurden und welche Risiken bestehen. Die MR-Größe sollte 400 Änderungszeilen nicht überschreiten. Bei größerem Umfang muss die Aufgabe in Teilaufgaben zerlegt werden. Für Dokumentation und Tests sind Ausnahmen akzeptabel, jedoch mit Erklärung.

Merge Request (MR) sollte automatisierte Tests für die neue Funktionalität enthalten. In GitLab kann die Coverage-Check-Richtlinie konfiguriert werden — der MR wird automatisch blockiert, wenn die Codeabdeckung unter einen Schwellenwert (z. B. 80%) fällt. Dadurch wird sichergestellt, dass neue Funktionalität die Gesamtqualität des Projekts nicht beeinträchtigt.

• Ein MR — eine Aufgabe: Große Änderungen in mehrere kleine MRs aufteilen
• Beschreibung mit Vorlage: .gitlab/merge_request_templates für Einheitlichkeit verwenden
• Größe bis 400 Zeilen: Große MRs werden langsamer und mit mehr Fehlern überprüft
• Tests sind obligatorisch: Neue Funktionen müssen durch Unit-Tests abgedeckt sein

MR-Beschreibungsvorlagen

GitLab unterstützt Merge Request-Vorlagen über Dateien in .gitlab/merge_request_templates/. Die Vorlage enthält Abschnitte: Was wurde getan, wie zu testen, verwandte Aufgaben und Checkliste. Die Verwendung von Vorlagen beschleunigt die MR-Erstellung und stellt sicher, dass Entwickler keine wichtigen Informationen vergessen. In der MR-Beschreibung müssen verwandte Issues (Closes #N) für die automatische Aufgabenabschluss beim Merge angegeben werden.