Merge Request (MR): ce este, cum să creezi și procesul de revizuire

Ce este Merge Request (MR)?

Merge Request (MR) — cerere de integrare a modificărilor dintr-o ramură Git în alta, care inițiază procesul de revizuire a codului și verificare automată. Spre deosebire de îmbinarea directă prin consolă, MR creează o procedură formală: dezvoltatorul descrie modificările, atribuie revizuitori, lansează CI/CD și primește feedback înainte de aplicarea modificărilor. Este elementul cheie al GitLab, dar mecanismul analogic în GitHub se numește Pull Request (PR).

Conform GitLab Documentation, 2026, în GitLab se creează peste 80 de milioane de Merge Request anual. Fiecare MR conține patru componente principale: descriere (description) cu contextul modificărilor, lista de commituri (commits), diferența de cod (diff) și discuția (discussion thread). Fără unul dintre aceste elemente, MR este considerat incomplet.

Merge Request (MR) rezolvă trei sarcini: previne modificările directe în ramurile protejate (main, develop), asigură controlul calității prin revizuire și păstrează istoricul discuțiilor pentru viitorii dezvoltatori. În GitLab, statusul MR este afișat în interfață cu indicatoare colorate: gri pentru Draft, portocaliu pentru în așteptare, verde pentru Approved, mov pentru Merged și roșu pentru Closed.

Terminologie: MR, PR și CR

Pe diferite platforme Git, Merge Request este numit diferit. GitLab folosește „Merge Request” (MR), GitHub — „Pull Request” (PR). Analogia — Change Request (CR) în Gerrit. Toate trei denotă același proces: cerere de integrare a modificărilor prin revizuirea codului. Alegerea termenului depinde doar de platforma utilizată în proiect.

# Creează o ramură cu modificări
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# MR poate fi creat prin UI GitLab/GitHub sau CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: care este diferența între GitLab și GitHub

Merge Request în GitLab și Pull Request în GitHub — sunt mecanisme funcțional identice cu nume diferite. Diferența se datorează istoriei: GitLab s-a poziționat inițial ca alternativă Self-Hosted la GitHub și a ales termenul „Merge Request” pentru procesul de îmbinare. GitHub, lansat mai devreme, a folosit „Pull Request” — cerere de a „trage” (pull) modificările în ramura principală.

Conform GitHub Docs, 2024, ambele instrumente suportă același set de funcții: descriere cu Markdown, atribuirea revizuitorilor, comentarea liniilor specifice de cod, statusuri de verificare și îmbinare automată la îndeplinirea condițiilor. Diferențele țin de interfață și capacități suplimentare.

Cum să creezi Merge Request: instrucțiuni pas cu pas

Crearea Merge Request (MR) începe cu publicarea ramurii cu modificări în depozitul la distanță. După push în GitLab sau GitHub, în interfață apare butonul „Create Merge Request” sau „Compare & Pull Request”. Dezvoltatorul completează descrierea, indică ramura țintă (de obicei develop sau main), atribuie revizuitori și adaugă etichete (labels).

Conform GitLab Documentation, 2025, un MR standard conține un titlu de până la 72 de caractere, o descriere cu șablon (template) și un link către sarcina (issue). Descrierea trebuie să răspundă la întrebările: ce s-a făcut, de ce, cum a fost testat. GitLab suportă închiderea automată a issue-urilor la îmbinare prin cuvintele cheie Closes, Fixes, Resolves.

# Exemplu de șablon .gitlab/merge_request_templates/default.md
## What does this MR do?

[Scurtă descriere a modificărilor: ce și de ce]

## How to test

1. Rulați ./gradlew test
2. Verificați LoginActivity cu token de test
3. Asigurați-vă că nu există regresie în AuthManager

## Related issues

Closes #142

Ciclul de viață al MR: de la Draft la Merged

Merge Request (MR) trece prin cinci statusuri în GitLab. Primul — Draft (ciornă), marcat cu prefixul „Draft:” în titlu și blochează îmbinarea. După pregătire, dezvoltatorul elimină Draft, iar MR trece în statusul Opened — începe revizuirea codului și se lansează pipeline-ul CI/CD.

Conform GitLab Docs, 2024, în statusul Opened, revizuitorii analizează diff-ul, lasă comentarii și solicită modificări prin Resolve Threads. Când toate discuțiile sunt închise și CI/CD trece cu succes, dezvoltatorul responsabil setează Approve. După aceea, MR poate fi îmbinat cu butonul Merge sau poate aștepta îmbinarea automată (Auto-merge).

GitLab suportă trei variante de status final: Merged (îmbinat cu succes), Closed (închis fără îmbinare, de exemplu, la renunțarea la o funcție) și Reopened (redeschis după închidere). Fiecare status este înregistrat în Activity Timeline MR pentru audit.

Statusuri automate și declanșatoare

GitLab actualizează automat statusul Merge Request la apariția evenimentelor: la push de commituri noi, Approvals sunt resetate, la pipeline CI cu succes statusul devine Pipeline passed, la eroare — Pipeline failed (îmbinarea este blocată). Se poate configura Auto-merge: MR se îmbină automat după CI cu succes și obținerea tuturor aprobărilor necesare.

• Draft — ciornă, CI se lansează, dar îmbinarea este blocată
• Opened — gata de revizuire, revizuitori atribuiți, pipeline activ
• Approved — s-a obținut numărul necesar de aprobări
• Merged — modificările au fost îmbinate în ramura țintă
• Closed — închis fără îmbinare

Reguli de revizuire a codului în Merge Request

Revizuirea codului în Merge Request (MR) — etapă obligatorie în majoritatea proiectelor comerciale. Conform datelor cercetării SmartBear, 2023, revizuirea codului cu MR reduce numărul de defecte cu 30–60% și accelerează integrarea noilor dezvoltatori. Regula principală — fiecare MR este verificat de cel puțin unul, de preferință doi dezvoltatori care nu au participat la scrierea codului.

Verificarea MR include cinci criterii: corectitudinea logicii, conformitatea cu stilul de cod, acoperirea cu teste, securitatea și performanța. În GitLab se pot configura Required Approvals — numărul obligatoriu de aprobări înainte de îmbinare, de exemplu, 2 aprobări pentru main și 1 pentru develop.

Discuția în MR se poartă în Threads — comentarii la linii specifice de cod. Fiecare discuție trebuie să fie resolved (închisă) înainte de îmbinare. Pentru a accelera revizuirea, se recomandă limitarea dimensiunii MR: 200–400 de linii de modificări. Conform Google Research (2022), MR-urile cu peste 400 de linii sunt verificate cu 30% mai puțin eficient.

Pipeline CI/CD în Merge Request

La crearea Merge Request (MR), pipeline-ul CI/CD se lansează automat. În GitLab, aceasta se întâmplă prin fișierul .gitlab-ci.yml, în GitHub — prin GitHub Actions workflow. Pipeline-ul include build-ul proiectului (build), rularea testelor unitare (unit tests), lintere (lint), analiza statică (SAST) și verificarea acoperirii codului.

Conform GitLab Blog, 2024, statusul pipeline-ului este afișat direct în MR: bifă verde (passed), cruce roșie (failed) sau cerc galben (running). Dacă pipeline-ul eșuează, GitLab blochează butonul Merge până la remediere. În setări se poate activa „Merge when pipeline succeeds” — îmbinare automată după pipeline cu succes.

# .gitlab-ci.yml — exemplu pentru proiect Android
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

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

Metode de îmbinare: Squash, Merge Commit, Fast-Forward

GitLab și GitHub oferă trei metode de îmbinare pentru Merge Request. Alegerea depinde de politica echipei și de puritatea istoricului dorită. Merge Commit — creează un commit de îmbinare separat, păstrând întregul istoric al ramurii de funcție. Squash — combină toate commiturile ramurii într-un singur commit pe ramura țintă. Fast-Forward — aplică commiturile liniar fără commit de îmbinare.

Conform GitLab Docs, 2025, Squash este preferat în proiecte cu densitate mare de commituri (20+ commituri într-o singură ramură de funcție). Fast-Forward este obligatoriu pentru Trunk-Based Development. Merge Commit este utilizat în Git Flow pentru păstrarea semanticii de ramificare.

• Merge Commit — păstrează istoricul, creează commit de îmbinare, potrivit pentru Git Flow
• Squash — combină toate commiturile într-unul singur, istoric curat, commiturile intermediare se pierd
• Fast-Forward — istoric liniar fără commit de îmbinare, obligatoriu în TBD

Cele mai bune practici: cum să scrii un MR bun

Un Merge Request (MR) de calitate reduce timpul de revizuire și scade numărul de erori. Prima regulă — un MR rezolvă o singură sarcină. Dacă modificările afectează mai multe funcționalități fără legătură, acestea trebuie împărțite în MR-uri separate. A doua — titlul MR trebuie să fie informativ: „Add OAuth2 authentication with Google provider” în loc de „Fix stuff” sau „Update code”.

Conform Google Engineering Practices, 2024, un MR bun conține descrierea contextului: de ce modificările sunt necesare, cum au fost testate, care sunt riscurile. Dimensiunea MR nu trebuie să depășească 400 de linii de modificări. Dacă volumul este mai mare — sarcina trebuie descompusă în subsarcini. Pentru documentație și teste, excepțiile sunt permise, dar cu explicații.

Merge Request (MR) trebuie să includă teste automate pentru noua funcționalitate. În GitLab se poate configura politica Coverage Check — MR se blochează automat dacă acoperirea codului a scăzut sub prag (de exemplu, 80%). Aceasta garantează că noua funcționalitate nu reduce calitatea generală a proiectului.

• Un MR — o sarcină: descompune modificările mari în mai multe MR-uri mici
• Descriere cu șablon: folosește .gitlab/merge_request_templates pentru uniformitate
• Dimensiune până la 400 de linii: MR-urile mari se verifică mai lent și cu mai multe erori
• Teste obligatorii: funcțiile noi trebuie acoperite cu teste unitare

Șabloane de descriere MR

GitLab suportă șabloane Merge Request prin fișierele .gitlab/merge_request_templates/. Șablonul include secțiuni: ce s-a făcut, cum să testezi, sarcinile asociate și lista de verificare. Utilizarea șabloanelor accelerează crearea MR și garantează că dezvoltatorii nu uită să indice informații importante. În descrierea MR se indică obligatoriu issue-ul asociat (Closes #N) pentru închiderea automată a sarcinilor la îmbinare.