Merge Request (MR): ano ito, paano gumawa at proseso ng review

Ano ang Merge Request (MR)?

Merge Request (MR) — kahilingang isama ang mga pagbabago mula sa isang sangay ng Git patungo sa isa pa, na nagpapasimula ng proseso ng code review at awtomatikong pagsusuri. Hindi tulad ng direktang pagsasama sa pamamagitan ng console, ang MR ay lumilikha ng pormal na pamamaraan: inilalarawan ng developer ang mga pagbabago, nagtatalaga ng mga reviewer, pinapatakbo ang CI/CD at tumatanggap ng feedback bago ilapat ang mga pagbabago. Ito ay pangunahing elemento ng GitLab, ngunit ang analogong mekanismo sa GitHub ay tinatawag na Pull Request (PR).

Ayon sa GitLab Documentation, 2026, sa GitLab ay ginagawa ang higit sa 80 milyong Merge Request taun-taon. Bawat MR ay naglalaman ng apat na pangunahing bahagi: paglalarawan (description) na may konteksto ng mga pagbabago, listahan ng mga commit (commits), pagkakaiba sa code (diff) at talakayan (discussion thread). Kung wala ang isa sa mga elementong ito, ang MR ay itinuturing na hindi kumpleto.

Merge Request (MR) ay lumulutas ng tatlong gawain: pinipigilan ang direktang pagbabago sa mga protektadong sangay (main, develop), tinitiyak ang kontrol sa kalidad sa pamamagitan ng review at pinapanatili ang kasaysayan ng mga talakayan para sa hinaharap na mga developer. Sa GitLab, ang status ng MR ay ipinapakita sa interface na may mga indikasyon ng kulay: kulay abo para sa Draft, kahel para sa naghihintay, berde para sa Approved, lila para sa Merged at pula para sa Closed.

Terminolohiya: MR, PR at CR

Sa iba't ibang platform ng Git, ang Merge Request ay tinatawag nang iba. GitLab ay gumagamit ng “Merge Request” (MR), GitHub — “Pull Request” (PR). Analohiya — Change Request (CR) sa Gerrit. Lahat ng tatlo ay tumutukoy sa parehong proseso: kahilingang isama ang mga pagbabago sa pamamagitan ng code review. Ang pagpili ng termino ay depende lamang sa platform na ginagamit sa proyekto.

# Gumawa ng sangay na may mga pagbabago
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# Ang MR ay maaaring gawin sa pamamagitan ng GitLab/GitHub UI o CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: ano ang pagkakaiba sa pagitan ng GitLab at GitHub

Merge Request sa GitLab at Pull Request sa GitHub — ay mga mekanismong magkapareho sa pag-andar na may magkaibang pangalan. Ang pagkakaiba ay dahil sa kasaysayan: ang GitLab ay una na nakaposisyon bilang Self-Hosted na alternatibo sa GitHub at pinili ang terminong “Merge Request” para sa proseso ng pagsasama. Ang GitHub, na inilunsad nang mas maaga, ay gumamit ng “Pull Request” — kahilingang “bunutin” (pull) ang mga pagbabago sa pangunahing sangay.

Ayon sa GitHub Docs, 2024, parehong sinusuportahan ng mga tool ang parehong hanay ng mga function: paglalarawan gamit ang Markdown, pagtatalaga ng mga reviewer, pagkomento sa mga partikular na linya ng code, mga status ng pagsusuri at awtomatikong pagsasama kapag natugunan ang mga kundisyon. Ang mga pagkakaiba ay nauugnay sa interface at karagdagang kakayahan.

Paano gumawa ng Merge Request: sunud-sunod na gabay

Ang paggawa ng Merge Request (MR) ay nagsisimula sa pag-publish ng sangay na may mga pagbabago sa malayuang repository. Pagkatapos ng push sa GitLab o GitHub, lalabas ang button na “Create Merge Request” o “Compare & Pull Request” sa interface. Pinupunan ng developer ang paglalarawan, itinuturo ang target na sangay (karaniwang develop o main), nagtatalaga ng mga reviewer at nagdaragdag ng mga label.

Ayon sa GitLab Documentation, 2025, ang standard na MR ay naglalaman ng pamagat hanggang 72 karakter, paglalarawan na may template at link sa gawain (issue). Ang paglalarawan ay dapat sumagot sa mga tanong: ano ang ginawa, bakit, paano ito nasubukan. Sinusuportahan ng GitLab ang awtomatikong pagsasara ng issue sa pagsasama sa pamamagitan ng mga keyword na Closes, Fixes, Resolves.

# Halimbawa ng template .gitlab/merge_request_templates/default.md
## What does this MR do?

[Maikling paglalarawan ng mga pagbabago: ano at bakit]

## How to test

1. Patakbuhin ang ./gradlew test
2. Suriin ang LoginActivity gamit ang test token
3. Tiyakin na walang regression sa AuthManager

## Related issues

Closes #142

Siklo ng buhay ng MR: mula Draft hanggang Merged

Merge Request (MR) ay dumadaan sa limang status sa GitLab. Una — Draft (borrador), minarkahan ng prefix na “Draft:” sa pamagat at hinaharangan ang pagsasama. Pagkatapos ng paghahanda, tinatanggal ng developer ang Draft at ang MR ay lumipat sa status na Opened — magsisimula ang code review at tatakbo ang pipeline ng CI/CD.

Ayon sa GitLab Docs, 2024, sa status na Opened, sinusuri ng mga reviewer ang diff, nag-iiwan ng mga komento at humihiling ng mga pagbabago sa pamamagitan ng Resolve Threads. Kapag ang lahat ng thread ay sarado at ang CI/CD ay matagumpay, ang responsableng developer ay naglalagay ng Approve. Pagkatapos nito, ang MR ay maaaring isama gamit ang Merge button o maghintay para sa awtomatikong pagsasama (Auto-merge).

GitLab ay sumusuporta sa tatlong variant ng huling status: Merged (matagumpay na naisama), Closed (isinara nang walang pagsasama, halimbawa, kapag binawasan ang feature) at Reopened (muling binuksan pagkatapos ng pagsasara). Bawat status ay naka-log sa Activity Timeline MR para sa audit.

Awtomatikong status at mga trigger

Awtomatikong ina-update ng GitLab ang status ng Merge Request kapag naganap ang mga kaganapan: sa push ng mga bagong commit, nire-reset ang Approvals; sa matagumpay na CI pipeline, ang status ay nagiging Pipeline passed; sa error — Pipeline failed (ang pagsasama ay hinarang). Maaaring i-configure ang Auto-merge: ang MR ay awtomatikong isasama pagkatapos ng matagumpay na CI at pagkakaroon ng lahat ng kinakailangang pag-apruba.

• Draft — borrador, tumatakbo ang CI ngunit ang pagsasama ay hinarang
• Opened — handa para sa review, mga reviewer ay itinalaga, pipeline ay aktibo
• Approved — nakuha na ang kinakailangang bilang ng mga pag-apruba
• Merged — ang mga pagbabago ay naisama sa target na sangay
• Closed — isinara nang walang pagsasama

Mga patakaran ng code review sa Merge Request

Code review sa Merge Request (MR) — sapilitang yugto sa karamihan ng mga komersyal na proyekto. Ayon sa datos ng pananaliksik ng SmartBear, 2023, ang code review na may MR ay nagbabawas ng bilang ng mga depekto ng 30–60% at nagpapabilis sa onboarding ng mga bagong developer. Pangunahing patakaran — bawat MR ay sinusuri ng hindi bababa sa isa, mas mabuti dalawang developer na hindi lumahok sa pagsulat ng code.

Pagsusuri ng MR ay may kasamang limang pamantayan: kawastuhan ng lohika, pagsunod sa istilo ng code, saklaw ng pagsubok, seguridad at pagganap. Sa GitLab, maaaring i-configure ang Required Approvals — sapilitang bilang ng mga pag-apruba bago ang pagsasama, halimbawa, 2 pag-apruba para sa main at 1 para sa develop.

Talakayan sa MR ay isinasagawa sa Threads — mga komento sa mga partikular na linya ng code. Bawat thread ay dapat na resolved (sarado) bago ang pagsasama. Upang pabilisin ang review, inirerekomenda na limitahan ang laki ng MR: 200–400 linya ng mga pagbabago. Ayon sa Google Research (2022), ang MR na may higit sa 400 linya ay sinusuri ng 30% na hindi gaanong epektibo.

Pipeline ng CI/CD sa Merge Request

Sa paggawa ng Merge Request (MR), ang pipeline ng CI/CD ay awtomatikong tumatakbo. Sa GitLab, ito ay nangyayari sa pamamagitan ng file na .gitlab-ci.yml, sa GitHub — sa pamamagitan ng GitHub Actions workflow. Ang pipeline ay may kasamang pagbuo ng proyekto (build), pagpapatakbo ng mga unit test (unit tests), linter (lint), static na pagsusuri (SAST) at pagsuri ng saklaw ng code.

Ayon sa GitLab Blog, 2024, ang status ng pipeline ay ipinapakita nang direkta sa MR: berdeng checkmark (passed), pulang krus (failed) o dilaw na bilog (running). Kung ang pipeline ay nabigo, hinaharangan ng GitLab ang Merge button hanggang sa maayos. Sa mga setting, maaaring i-on ang “Merge when pipeline succeeds” — awtomatikong pagsasama pagkatapos ng matagumpay na pipeline.

# .gitlab-ci.yml — halimbawa para sa proyektong Android
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

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

Mga paraan ng pagsasama: Squash, Merge Commit, Fast-Forward

GitLab at GitHub ay nag-aalok ng tatlong paraan ng pagsasama para sa Merge Request. Ang pagpili ay depende sa patakaran ng koponan at nais na kalinisan ng kasaysayan. Merge Commit — gumagawa ng hiwalay na commit ng pagsasama, pinapanatili ang buong kasaysayan ng feature na sangay. Squash — pinagsasama ang lahat ng commit ng sangay sa isang commit sa target na sangay. Fast-Forward — inilalapat ang mga commit nang linear nang walang commit ng pagsasama.

Ayon sa GitLab Docs, 2025, ang Squash ay mas gusto sa mga proyekto na may mataas na densidad ng commit (20+ commit sa isang feature na sangay). Ang Fast-Forward ay sapilitan para sa Trunk-Based Development. Ang Merge Commit ay ginagamit sa Git Flow upang mapanatili ang semantika ng pagsasanga.

• Merge Commit — pinapanatili ang kasaysayan, gumagawa ng commit ng pagsasama, angkop para sa Git Flow
• Squash — pinagsasama ang lahat ng commit sa isa, malinis na kasaysayan, nawawala ang mga intermediate na commit
• Fast-Forward — linear na kasaysayan nang walang commit ng pagsasama, sapilitan sa TBD

Pinakamahusay na kasanayan: paano sumulat ng magandang MR

Ang kalidad na Merge Request (MR) ay nagpapaikli sa oras ng review at nagbabawas ng bilang ng mga pagkakamali. Unang patakaran — isang MR ay lumulutas ng isang gawain. Kung ang mga pagbabago ay nakakaapekto sa maraming hindi kaugnay na feature, dapat silang hatiin sa magkakahiwalay na MR. Pangalawa — ang pamagat ng MR ay dapat na nagbibigay-kaalaman: “Add OAuth2 authentication with Google provider” sa halip na “Fix stuff” o “Update code”.

Ayon sa Google Engineering Practices, 2024, ang magandang MR ay naglalaman ng paglalarawan ng konteksto: bakit kinakailangan ang mga pagbabago, paano sila nasubukan, ano ang mga panganib. Ang laki ng MR ay hindi dapat lumampas sa 400 linya ng mga pagbabago. Kung mas malaki ang volume — ang gawain ay dapat na mabulok sa mga sub-task. Para sa dokumentasyon at mga test, ang mga eksepsyon ay pinahihintulutan, ngunit may paliwanag.

Merge Request (MR) ay dapat may kasamang awtomatikong test para sa bagong pag-andar. Sa GitLab, maaaring i-configure ang patakaran ng Coverage Check — ang MR ay awtomatikong haharang kung ang saklaw ng code ay bumaba sa ibaba ng threshold (hal., 80%). Ito ay ginagarantiyahan na ang bagong pag-andar ay hindi nagpapababa sa pangkalahatang kalidad ng proyekto.

• Isang MR — isang gawain: i-decompose ang malalaking pagbabago sa ilang maliliit na MR
• Paglalarawan na may template: gamitin ang .gitlab/merge_request_templates para sa pagkakapareho
• Laki hanggang 400 linya: ang malalaking MR ay sinusuri nang mas mabagal at may mas maraming pagkakamali
• Sapilitan ang mga test: ang mga bagong feature ay dapat saklawin ng mga unit test

Mga template ng paglalarawan ng MR

Sinusuportahan ng GitLab ang mga template ng Merge Request sa pamamagitan ng mga file na .gitlab/merge_request_templates/. Ang template ay may mga seksyon: ano ang ginawa, paano mag-test, mga kaugnay na gawain at checklist. Ang paggamit ng mga template ay nagpapabilis sa paggawa ng MR at ginagarantiyahan na hindi makalimutan ng mga developer na isama ang mahalagang impormasyon. Sa paglalarawan ng MR, ang kaugnay na issue (Closes #N) ay sapilitang ipinapahiwatig para sa awtomatikong pagsasara ng mga gawain sa pagsasama.