Merge Request (MR): mi ez, hogyan kell létrehozni és a felülvizsgálati folyamat

Mi az a Merge Request (MR)?

Merge Request (MR) — kérelem a változtatások integrálására az egyik Git ágból a másikba, amely elindítja a kódellenőrzés és automatikus ellenőrzés folyamatát. Ellentétben a közvetlen konzolos egyesítéssel, az MR formális eljárást hoz létre: a fejlesztő leírja a változtatásokat, kijelöli az ellenőröket, elindítja a CI/CD-t, és visszajelzést kap a változtatások alkalmazása előtt. Ez a GitLab kulcseleme, de a GitHubban hasonló mechanizmust Pull Request-nek (PR) hívják.

A GitLab Documentation, 2026 szerint a GitLabban évente több mint 80 millió Merge Request jön létre. Minden MR négy fő összetevőből áll: leírás (description) a változtatások kontextusával, commitok listája (commits), kódkülönbség (diff) és megbeszélés (discussion thread). Ezen elemek egyike nélkül az MR hiányosnak tekinthető.

Merge Request (MR) három feladatot old meg: megakadályozza a közvetlen változtatásokat a védett ágakban (main, develop), biztosítja a minőség-ellenőrzést a felülvizsgálaton keresztül, és megőrzi a megbeszélések történetét a jövőbeli fejlesztők számára. A GitLabban az MR állapota színes jelzésekkel jelenik meg a felületen: szürke a Draft, narancssárga a várakozó, zöld az Approved, lila a Merged és piros a Closed.

Terminológia: MR, PR és CR

A különböző Git platformokon a Merge Request eltérő néven szerepel. A GitLab a „Merge Request” (MR), a GitHub — a „Pull Request” (PR) kifejezést használja. Analógia — Change Request (CR) a Gerritben. Mindhárom ugyanazt a folyamatot jelöli: kérelem a változtatások kódellenőrzésen keresztüli integrálására. A kifejezés megválasztása csak a projektben használt platformtól függ.

# Hozzon létre egy ágat változtatásokkal
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# Az MR a GitLab/GitHub UI-n vagy CLI-n keresztül hozható létre:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: mi a különbség a GitLab és a GitHub között

Merge Request a GitLabban és Pull Request a GitHubban — funkcionálisan azonos mechanizmusok, különböző elnevezésekkel. A különbség történelmi okokra vezethető vissza: a GitLab eredetileg a GitHub Self-Hosted alternatívájaként pozícionálta magát, és a „Merge Request” kifejezést választotta az egyesítési folyamatra. A korábban elindított GitHub a „Pull Request” — kérelem a változtatások „behúzására” (pull) a főágba — kifejezést használta.

A GitHub Docs, 2024 szerint mindkét eszköz ugyanazt a funkciókészletet támogatja: leírás Markdown-nal, ellenőrök kijelölése, konkrét kódsorok kommentálása, ellenőrzési állapotok és automatikus egyesítés a feltételek teljesülése esetén. A különbségek a felületet és a további lehetőségeket érintik.

Hogyan kell létrehozni egy Merge Request-et: lépésről lépésre útmutató

A Merge Request (MR) létrehozása a változtatásokat tartalmazó ág közzétételével kezdődik a távoli repozitóriumban. A GitLabba vagy GitHubba történő push után megjelenik a „Create Merge Request” vagy „Compare & Pull Request” gomb a felületen. A fejlesztő kitölti a leírást, megadja a célágat (általában develop vagy main), kijelöli az ellenőröket, és hozzáadja a címkéket (labels).

A GitLab Documentation, 2025 szerint egy szabványos MR 72 karakterig terjedő címet, sablonos (template) leírást és hivatkozást tartalmaz a feladatra (issue). A leírásnak válaszolnia kell a kérdésekre: mit csináltak, miért, hogyan tesztelték. A GitLab támogatja az issue-k automatikus lezárását egyesítéskor a Closes, Fixes, Resolves kulcsszavakon keresztül.

# Példa sablon: .gitlab/merge_request_templates/default.md
## What does this MR do?

[A változtatások rövid leírása: mit és miért]

## How to test

1. Futtassa a(z) ./gradlew test
2. Ellenőrizze a(z) LoginActivity elemet teszt tokennel
3. Győződjön meg arról, hogy nincs regresszió a(z) AuthManager

## Related issues

Closes #142

Az MR életciklusa: a Draft-tól a Merged-ig

Merge Request (MR) öt állapoton megy keresztül a GitLabban. Az első — Draft (vázlat), amelyet a „Draft:” előtag jelöl a címben, és blokkolja az egyesítést. Az előkészítés után a fejlesztő eltávolítja a Draft-ot, és az MR az Opened állapotba lép — elindul a kódellenőrzés és a CI/CD pipeline.

A GitLab Docs, 2024 szerint az Opened állapotban az ellenőrök átnézik a diff-et, megjegyzéseket hagynak, és a Resolve Threads segítségével változtatásokat kérnek. Amikor az összes szál le van zárva, és a CI/CD sikeresen lefut, a felelős fejlesztő beállítja az Approve-ot. Ezután az MR egyesíthető a Merge gombbal, vagy várható az automatikus egyesítés (Auto-merge).

GitLab három végső állapot változatot támogat: Merged (sikeresen egyesítve), Closed (egyesítés nélkül lezárva, pl. egy funkció elvetésekor) és Reopened (újranyitás a lezárás után). Minden állapot naplózásra kerül az Activity Timeline MR-ben audit céljából.

Automatikus állapotok és triggerek

A GitLab automatikusan frissíti a Merge Request állapotát események bekövetkeztekor: új commitok push-jakor az Approvals visszaállításra kerül, sikeres CI pipeline esetén az állapot Pipeline passed lesz, hiba esetén — Pipeline failed (az egyesítés blokkolva). Az Auto-merge konfigurálható: az MR automatikusan egyesül a sikeres CI és az összes szükséges jóváhagyás megszerzése után.

• Draft — vázlat, a CI elindul, de az egyesítés blokkolva van
• Opened — készen áll a felülvizsgálatra, ellenőrök kijelölve, pipeline aktív
• Approved — a szükséges számú jóváhagyás megtörtént
• Merged — a változtatások egyesítve a célágba
• Closed — egyesítés nélkül lezárva

A kódellenőrzés szabályai a Merge Request-ben

Kódellenőrzés a Merge Request-ben (MR) — kötelező szakasz a legtöbb kereskedelmi projektben. A SmartBear, 2023 kutatási adatai szerint az MR-rel végzett kódellenőrzés 30–60%-kal csökkenti a hibák számát, és felgyorsítja az új fejlesztők betanulását. Fő szabály — minden MR-t legalább egy, lehetőleg két olyan fejlesztő ellenőriz, aki nem vett részt a kód megírásában.

Az MR ellenőrzése öt kritériumot foglal magában: a logika helyességét, a kódstílusnak való megfelelést, a tesztlefedettséget, a biztonságot és a teljesítményt. A GitLabban konfigurálhatók a Required Approvals — az egyesítés előtt kötelező jóváhagyások száma, például 2 jóváhagyás a main és 1 a develop számára.

Megbeszélés az MR-ben Threads-ben — a kód adott soraihoz fűzött megjegyzésekben történik. Minden szálnak resolved (lezárva) kell lennie az egyesítés előtt. Az ellenőrzés felgyorsításához ajánlott korlátozni az MR méretét: 200–400 sor változtatás. A Google Research (2022) adatai szerint a 400 sornál nagyobb MR-ek 30%-kal kevésbé hatékonyan ellenőrizhetők.

CI/CD pipeline a Merge Request-ben

A Merge Request (MR) létrehozásakor automatikusan elindul a CI/CD pipeline. A GitLabban ez a .gitlab-ci.yml fájlon keresztül, a GitHubban — a GitHub Actions workflow segítségével történik. A pipeline tartalmazza a projekt felépítését (build), a modultesztek (unit tests) futtatását, a lintereket (lint), a statikus elemzést (SAST) és a kódlefedettség ellenőrzését.

A GitLab Blog, 2024 szerint a pipeline állapota közvetlenül az MR-ben jelenik meg: zöld pipa (passed), piros kereszt (failed) vagy sárga kör (running). Ha a pipeline meghiúsul, a GitLab blokkolja a Merge gombot a javításig. A beállításokban engedélyezhető a „Merge when pipeline succeeds” — automatikus egyesítés sikeres pipeline után.

# .gitlab-ci.yml — példa Android projekthez
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

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

Egyesítési módszerek: Squash, Merge Commit, Fast-Forward

GitLab és GitHub három egyesítési módszert kínál a Merge Request-hez. A választás a csapat politikájától és a kívánt előzmény-tisztaságtól függ. Merge Commit — külön egyesítési commitot hoz létre, megtartva a feature ág teljes előzményét. Squash — az ág összes commitját egyetlen commitba egyesíti a célágon. Fast-Forward — lineárisan alkalmazza a commitokat egyesítési commit nélkül.

A GitLab Docs, 2025 szerint a Squash előnyös a magas commit-sűrűségű projektekben (20+ commit egyetlen feature ágban). A Fast-Forward kötelező a Trunk-Based Development számára. A Merge Commit-ot a Git Flow-ban használják az elágazási szemantika megőrzésére.

• Merge Commit — megtartja az előzményeket, egyesítési commitot hoz létre, alkalmas Git Flow-hoz
• Squash — az összes commitot egyesíti egyben, tiszta előzmény, a köztes commitok elvesznek
• Fast-Forward — lineáris előzmény egyesítési commit nélkül, kötelező a TBD-ben

Legjobb gyakorlatok: hogyan írjunk jó MR-t

Minőségi Merge Request (MR) lerövidíti az ellenőrzési időt és csökkenti a hibák számát. Első szabály — egy MR egy feladatot old meg. Ha a változtatások több nem kapcsolódó funkciót érintenek, azokat külön MR-ekre kell bontani. Második — az MR címe legyen informatív: „Fix stuff” vagy „Update code” helyett „Add OAuth2 authentication with Google provider”.

A Google Engineering Practices, 2024 szerint egy jó MR tartalmazza a kontextus leírását: miért szükségesek a változtatások, hogyan lettek tesztelve, mik a kockázatok. Az MR mérete nem haladhatja meg a 400 sor változtatást. Ha a terjedelem nagyobb — a feladatot részt feladatokra kell bontani. A dokumentáció és tesztek esetében a kivételek megengedettek, de magyarázattal.

Merge Request (MR) tartalmaznia kell automatikus teszteket az új funkciókhoz. A GitLabban konfigurálható a Coverage Check politika — az MR automatikusan blokkolódik, ha a kódlefedettség a küszöbérték (pl. 80%) alá esik. Ez garantálja, hogy az új funkció nem csökkenti a projekt általános minőségét.

• Egy MR — egy feladat: bontsa a nagy változtatásokat több kis MR-re
• Leírás sablonnal: használja a .gitlab/merge_request_templates fájlokat az egységességért
• Méret 400 sorig: a nagy MR-ek lassabban és több hibával ellenőrizhetők
• Tesztek kötelezőek: az új funkciókat modultesztekkel kell lefedni

MR leírás sablonok

A GitLab támogatja a Merge Request sablonokat a .gitlab/merge_request_templates/ fájlokon keresztül. A sablon szekciókat tartalmaz: mit csináltak, hogyan kell tesztelni, kapcsolódó feladatok és ellenőrző lista. A sablonok használata felgyorsítja az MR létrehozását, és garantálja, hogy a fejlesztők nem felejtenek el fontos információkat megadni. Az MR leírásában kötelező feltüntetni a kapcsolódó issue-t (Closes #N) a feladatok automatikus lezárásához az egyesítéskor.