Merge Request (MR): co to jest, jak utworzyć i proces recenzji

Co to jest Merge Request (MR)?

Merge Request (MR) — prośba o integrację zmian z jednej gałęzi Git do drugiej, która inicjuje proces code review i automatycznego sprawdzenia. W przeciwieństwie do bezpośredniego scalania przez konsolę, MR tworzy formalną procedurę: programista opisuje zmiany, przypisuje recenzentów, uruchamia CI/CD i otrzymuje informację zwrotną przed zastosowaniem zmian. To kluczowy element GitLab, ale analogiczny mechanizm w GitHub nazywa się Pull Request (PR).

Według GitLab Documentation, 2026, w GitLab tworzy się ponad 80 milionów Merge Request rocznie. Każdy MR zawiera cztery główne komponenty: opis (description) z kontekstem zmian, listę commitów (commits), różnicę w kodzie (diff) i dyskusję (discussion thread). Bez jednego z tych elementów MR jest uważany za niekompletny.

Merge Request (MR) rozwiązuje trzy zadania: zapobiega bezpośrednim zmianom w chronionych gałęziach (main, develop), zapewnia kontrolę jakości przez recenzję i zachowuje historię dyskusji dla przyszłych programistów. W GitLab status MR jest wyświetlany w interfejsie z kolorową indykacją: szary dla Draft, pomarańczowy dla oczekiwania, zielony dla Approved, fioletowy dla Merged i czerwony dla Closed.

Terminologia: MR, PR i CR

Na różnych platformach Git Merge Request jest nazywany inaczej. GitLab używa „Merge Request” (MR), GitHub — „Pull Request” (PR). Analogia — Change Request (CR) w Gerrit. Wszystkie trzy oznaczają ten sam proces: prośbę o integrację zmian przez code review. Wybór terminu zależy tylko od platformy używanej w projekcie.

# Utwórz gałąź ze zmianami
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# MR można utworzyć przez UI GitLab/GitHub lub CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: jaka jest różnica między GitLab a GitHub

Merge Request w GitLab i Pull Request w GitHub — to funkcjonalnie identyczne mechanizmy z różnymi nazwami. Różnica wynika z historii: GitLab początkowo pozycjonował się jako Self-Hosted alternatywa dla GitHub i wybrał termin „Merge Request” dla procesu scalania. GitHub, uruchomiony wcześniej, użył „Pull Request” — prośba o „pociągnięcie” (pull) zmian do głównej gałęzi.

Według GitHub Docs, 2024, oba narzędzia obsługują ten sam zestaw funkcji: opis z Markdown, przypisanie recenzentów, komentowanie konkretnych linii kodu, statusy sprawdzeń i automatyczne scalanie po spełnieniu warunków. Różnice dotyczą interfejsu i dodatkowych możliwości.

Jak utworzyć Merge Request: instrukcja krok po kroku

Tworzenie Merge Request (MR) zaczyna się od opublikowania gałęzi ze zmianami w zdalnym repozytorium. Po push do GitLab lub GitHub w interfejsie pojawia się przycisk „Create Merge Request” lub „Compare & Pull Request”. Programista wypełnia opis, wskazuje gałąź docelową (target, zazwyczaj develop lub main), przypisuje recenzentów i dodaje etykiety (labels).

Według GitLab Documentation, 2025, standardowy MR zawiera tytuł do 72 znaków, opis z szablonem (template) i link do zadania (issue). Opis powinien odpowiadać na pytania: co zostało zrobione, dlaczego, jak było testowane. GitLab obsługuje automatyczne zamykanie issue przy mergu przez słowa kluczowe Closes, Fixes, Resolves.

# Przykład szablonu .gitlab/merge_request_templates/default.md
## What does this MR do?

[Krótki opis zmian: co i dlaczego]

## How to test

1. Uruchom ./gradlew test
2. Sprawdź LoginActivity z tokenem testowym
3. Upewnić się, że nie ma regresji w AuthManager

## Related issues

Closes #142

Cykl życia MR: od Draft do Merged

Merge Request (MR) przechodzi pięć statusów w GitLab. Pierwszy — Draft (szkic), oznaczany prefiksem „Draft:” w tytule i blokujący scalanie. Po przygotowaniu programista usuwa Draft, a MR przechodzi do statusu Opened — zaczyna się code review i uruchamia pipeline CI/CD.

Według GitLab Docs, 2024, w statusie Opened recenzenci przeglądają diff, zostawiają komentarze i żądają zmian przez Resolve Threads. Gdy wszystkie wątki są zamknięte, a CI/CD przechodzi pomyślnie, odpowiedzialny programista ustawia Approve. Następnie MR można scalić przyciskiem Merge albo poczekać na automatyczne scalanie (Auto-merge).

GitLab obsługuje trzy warianty statusu końcowego: Merged (pomyślnie scalone), Closed (zamknięte bez scalenia, np. przy rezygnacji z funkcji) i Reopened (ponowne otwarcie po zamknięciu). Każdy status jest logowany w Activity Timeline MR do audytu.

Automatyczne statusy i wyzwalacze

GitLab automatycznie aktualizuje status Merge Request przy wystąpieniu zdarzeń: przy push nowych commitów resetowane są Approvals, przy pomyślnym CI pipeline status staje się Pipeline passed, przy błędzie — Pipeline failed (merge jest blokowany). Można skonfigurować Auto-merge: MR scala się automatycznie po pomyślnym CI i uzyskaniu wszystkich wymaganych zatwierdzeń.

• Draft — szkic, CI uruchamia się, ale merge jest zablokowany
• Opened — gotowy do recenzji, przypisani recenzenci, pipeline aktywny
• Approved — uzyskano wymaganą liczbę zatwierdzeń
• Merged — zmiany scalone z gałęzią docelową
• Closed — zamknięty bez scalenia

Zasady code review w Merge Request

Code review w Merge Request (MR) — obowiązkowy etap w większości komercyjnych projektów. Według danych badania SmartBear, 2023, code review z MR zmniejsza liczbę defektów o 30–60% i przyspiesza wdrożenie nowych programistów. Główna zasada — każdy MR sprawdza co najmniej jeden, a najlepiej dwóch programistów, którzy nie brali udziału w pisaniu kodu.

Sprawdzenie MR obejmuje pięć kryteriów: poprawność logiki, zgodność z code style, pokrycie testami, bezpieczeństwo i wydajność. W GitLab można skonfigurować Required Approvals — wymaganą liczbę zatwierdzeń przed mergem, np. 2 zatwierdzenia dla main i 1 dla develop.

Dyskusja w MR prowadzona jest w Threads — komentarzach do konkretnych linii kodu. Każdy wątek musi być resolved (zamknięty) przed scaleniem. Aby przyspieszyć recenzję, zaleca się ograniczać rozmiar MR: 200–400 linii zmian. Według danych Google Research (2022), MR o objętości ponad 400 linii są sprawdzane o 30% mniej efektywnie.

Pipeline CI/CD w Merge Request

Przy tworzeniu Merge Request (MR) automatycznie uruchamia się pipeline CI/CD. W GitLab odbywa się to przez plik .gitlab-ci.yml, w GitHub — przez GitHub Actions workflow. Pipeline obejmuje budowę projektu (build), uruchomienie testów jednostkowych (unit tests), lintery (lint), analizę statyczną (SAST) i sprawdzenie pokrycia kodu.

Według GitLab Blog, 2024, status pipeline jest wyświetlany bezpośrednio w MR: zielony znacznik (passed), czerwony krzyżyk (failed) lub żółte kółko (running). Jeśli pipeline upadnie, GitLab blokuje przycisk Merge do momentu naprawy. W ustawieniach można włączyć „Merge when pipeline succeeds” — automatyczny merge po pomyślnym pipeline.

# .gitlab-ci.yml — przykład dla projektu Android
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

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

Metody scalania: Squash, Merge Commit, Fast-Forward

GitLab i GitHub oferują trzy metody scalania dla Merge Request. Wybór zależy od polityki zespołu i wymaganej czystości historii. Merge Commit — tworzy osobny commit scalania, zachowując całą historię gałęzi funkcjonalnej. Squash — łączy wszystkie commity gałęzi w jeden commit na gałęzi docelowej. Fast-Forward — stosuje commity liniowo bez commitu scalania.

Według GitLab Docs, 2025, Squash jest preferowany w projektach z wysoką gęstością commitów (20+ commitów w jednej gałęzi funkcjonalnej). Fast-Forward jest obowiązkowy dla Trunk-Based Development. Merge Commit jest używany w Git Flow do zachowania semantyki rozgałęzień.

• Merge Commit — zachowuje historię, tworzy commit scalania, odpowiedni dla Git Flow
• Squash — łączy wszystkie commity w jeden, czysta historia, tracone są pośrednie commity
• Fast-Forward — liniowa historia bez commitu scalania, obowiązkowy w TBD

Najlepsze praktyki: jak napisać dobry MR

Jakościowy Merge Request (MR) skraca czas recenzji i zmniejsza liczbę błędów. Pierwsza zasada — jeden MR rozwiązuje jedno zadanie. Jeśli zmiany dotyczą kilku niepowiązanych funkcji, należy je podzielić na osobne MR. Druga — tytuł MR powinien być informacyjny: „Add OAuth2 authentication with Google provider” zamiast „Fix stuff” lub „Update code”.

Według Google Engineering Practices, 2024, dobry MR zawiera opis kontekstu: dlaczego zmiany są konieczne, jak były testowane, jakie są ryzyka. Rozmiar MR nie powinien przekraczać 400 linii zmian. Jeśli objętość jest większa — zadanie należy zdekomponować na podzadania. Dla dokumentacji i testów wyjątki są dopuszczalne, ale z wyjaśnieniem.

Merge Request (MR) powinien zawierać automatyczne testy nowej funkcjonalności. W GitLab można skonfigurować politykę Coverage Check — MR automatycznie blokuje się, jeśli pokrycie kodu spadło poniżej progu (np. 80%). Gwarantuje to, że nowa funkcjonalność nie obniża ogólnej jakości projektu.

• Jeden MR — jedno zadanie: dekomponuj duże zmiany na kilka małych MR
• Opis z szablonem: używaj .gitlab/merge_request_templates dla jednolitości
• Rozmiar do 400 linii: duże MR są sprawdzane wolniej i z większą liczbą błędów
• Testy obowiązkowe: nowe funkcje powinny być pokryte testami jednostkowymi

Szablony opisu MR

GitLab obsługuje szablony Merge Request przez pliki .gitlab/merge_request_templates/. Szablon zawiera sekcje: co zostało zrobione, jak testować, powiązane zadania i checklista. Używanie szablonów przyspiesza tworzenie MR i gwarantuje, że programiści nie zapomną podać ważnych informacji. W opisie MR obowiązkowo wskazuje się powiązane issue (Closes #N) do automatycznego zamykania zadań przy mergu.