Merge Request (MR): apa itu, cara membuat dan proses review

Apa itu Merge Request (MR)?

Merge Request (MR) — permintaan untuk mengintegrasikan perubahan dari satu cabang Git ke cabang lain, yang memulai proses code review dan pemeriksaan otomatis. Berbeda dengan penggabungan langsung melalui konsol, MR membuat prosedur formal: pengembang menjelaskan perubahan, menunjuk reviewer, menjalankan CI/CD, dan mendapatkan umpan balik sebelum perubahan diterapkan. Ini adalah elemen kunci GitLab, tetapi mekanisme serupa di GitHub disebut Pull Request (PR).

Menurut GitLab Documentation, 2026, di GitLab dibuat lebih dari 80 juta Merge Request setiap tahunnya. Setiap MR berisi empat komponen utama: deskripsi (description) dengan konteks perubahan, daftar commit (commits), perbedaan kode (diff), dan diskusi (discussion thread). Tanpa salah satu elemen ini, MR dianggap tidak lengkap.

Merge Request (MR) menyelesaikan tiga tugas: mencegah perubahan langsung di cabang yang dilindungi (main, develop), memastikan kontrol kualitas melalui review, dan menyimpan riwayat diskusi untuk pengembang masa depan. Di GitLab, status MR ditampilkan di antarmuka dengan indikasi warna: abu-abu untuk Draft, oranye untuk menunggu, hijau untuk Approved, ungu untuk Merged, dan merah untuk Closed.

Terminologi: MR, PR, dan CR

Di berbagai platform Git, Merge Request disebut berbeda. GitLab menggunakan “Merge Request” (MR), GitHub — “Pull Request” (PR). Analogi — Change Request (CR) di Gerrit. Ketiganya merujuk pada proses yang sama: permintaan integrasi perubahan melalui code review. Pilihan istilah hanya tergantung pada platform yang digunakan dalam proyek.

# Buat cabang dengan perubahan
git checkout -b feature/add-auth
git commit -m "Add OAuth2 authentication flow"
git push origin feature/add-auth

# MR dapat dibuat melalui UI GitLab/GitHub atau CLI:
gh pr create --title "Add OAuth2 authentication flow" \
  --body "Implements OAuth2 with Google and Apple providers" \
  --reviewer "team-lead"

MR vs PR: apa perbedaan antara GitLab dan GitHub

Merge Request di GitLab dan Pull Request di GitHub — adalah mekanisme yang secara fungsional identik dengan nama yang berbeda. Perbedaan disebabkan oleh sejarah: GitLab awalnya diposisikan sebagai alternatif Self-Hosted untuk GitHub dan memilih istilah “Merge Request” untuk proses penggabungan. GitHub, yang diluncurkan lebih awal, menggunakan “Pull Request” — permintaan untuk “menarik” (pull) perubahan ke cabang utama.

Menurut GitHub Docs, 2024, kedua alat mendukung rangkaian fungsi yang sama: deskripsi dengan Markdown, penunjukan reviewer, komentar pada baris kode tertentu, status pemeriksaan, dan penggabungan otomatis saat kondisi terpenuhi. Perbedaan terkait antarmuka dan kemampuan tambahan.

Cara membuat Merge Request: panduan langkah demi langkah

Pembuatan Merge Request (MR) dimulai dengan mempublikasikan cabang dengan perubahan di repositori jarak jauh. Setelah push ke GitLab atau GitHub, muncul tombol “Create Merge Request” atau “Compare & Pull Request” di antarmuka. Pengembang mengisi deskripsi, menunjukkan cabang target (biasanya develop atau main), menunjuk reviewer, dan menambahkan label.

Menurut GitLab Documentation, 2025, MR standar berisi judul hingga 72 karakter, deskripsi dengan templat (template), dan tautan ke tugas (issue). Deskripsi harus menjawab pertanyaan: apa yang dilakukan, mengapa, bagaimana diuji. GitLab mendukung penutupan otomatis issue saat penggabungan melalui kata kunci Closes, Fixes, Resolves.

# Contoh templat .gitlab/merge_request_templates/default.md
## What does this MR do?

[Deskripsi singkat perubahan: apa dan mengapa]

## How to test

1. Jalankan ./gradlew test
2. Periksa LoginActivity dengan token pengujian
3. Pastikan tidak ada regresi di AuthManager

## Related issues

Closes #142

Siklus hidup MR: dari Draft hingga Merged

Merge Request (MR) melalui lima status di GitLab. Pertama — Draft (draf), ditandai dengan prefiks “Draft:” di judul dan memblokir penggabungan. Setelah siap, pengembang menghapus Draft, dan MR beralih ke status Opened — code review dimulai dan pipeline CI/CD dijalankan.

Menurut GitLab Docs, 2024, dalam status Opened, reviewer meninjau diff, meninggalkan komentar, dan meminta perubahan melalui Resolve Threads. Ketika semua thread ditutup dan CI/CD berhasil, pengembang yang bertanggung jawab memberikan Approve. Setelah itu, MR dapat digabungkan dengan tombol Merge atau menunggu penggabungan otomatis (Auto-merge).

GitLab mendukung tiga varian status akhir: Merged (berhasil digabungkan), Closed (ditutup tanpa penggabungan, misalnya saat membatalkan fitur), dan Reopened (dibuka kembali setelah ditutup). Setiap status dicatat dalam Activity Timeline MR untuk audit.

Status otomatis dan pemicu

GitLab secara otomatis memperbarui status Merge Request saat peristiwa terjadi: saat push commit baru, Approvals direset; saat pipeline CI berhasil, status menjadi Pipeline passed; saat terjadi kesalahan — Pipeline failed (penggabungan diblokir). Auto-merge dapat dikonfigurasi: MR digabungkan secara otomatis setelah CI berhasil dan semua persetujuan yang diperlukan diperoleh.

• Draft — draf, CI berjalan tetapi penggabungan diblokir
• Opened — siap untuk review, reviewer ditunjuk, pipeline aktif
• Approved — jumlah persetujuan yang diperlukan telah diperoleh
• Merged — perubahan telah digabungkan ke cabang target
• Closed — ditutup tanpa penggabungan

Aturan code review dalam Merge Request

Code review dalam Merge Request (MR) — tahap wajib di sebagian besar proyek komersial. Menurut data penelitian SmartBear, 2023, code review dengan MR mengurangi jumlah cacat sebesar 30–60% dan mempercepat orientasi pengembang baru. Aturan utama — setiap MR diperiksa oleh setidaknya satu, sebaiknya dua pengembang yang tidak berpartisipasi dalam penulisan kode.

Pemeriksaan MR mencakup lima kriteria: kebenaran logika, kepatuhan terhadap gaya kode, cakupan pengujian, keamanan, dan kinerja. Di GitLab, Required Approvals dapat dikonfigurasi — jumlah persetujuan wajib sebelum penggabungan, misalnya 2 persetujuan untuk main dan 1 untuk develop.

Diskusi dalam MR dilakukan dalam Threads — komentar pada baris kode tertentu. Setiap thread harus resolved (ditutup) sebelum penggabungan. Untuk mempercepat review, disarankan membatasi ukuran MR: 200–400 baris perubahan. Menurut Google Research (2022), MR dengan volume lebih dari 400 baris diperiksa 30% kurang efisien.

Pipeline CI/CD dalam Merge Request

Saat pembuatan Merge Request (MR), pipeline CI/CD secara otomatis dijalankan. Di GitLab, ini terjadi melalui file .gitlab-ci.yml, di GitHub — melalui GitHub Actions workflow. Pipeline mencakup pembangunan proyek (build), menjalankan pengujian unit (unit tests), linter (lint), analisis statis (SAST), dan pemeriksaan cakupan kode.

Menurut GitLab Blog, 2024, status pipeline ditampilkan langsung di MR: centang hijau (passed), silang merah (failed), atau lingkaran kuning (running). Jika pipeline gagal, GitLab memblokir tombol Merge hingga diperbaiki. Dalam pengaturan, dapat diaktifkan “Merge when pipeline succeeds” — penggabungan otomatis setelah pipeline berhasil.

# .gitlab-ci.yml — contoh untuk proyek Android
test:
  stage: test
  script:
    - ./gradlew ktlintCheck
    - ./gradlew testDebugUnitTest
  only:
    - merge_requests

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

Metode penggabungan: Squash, Merge Commit, Fast-Forward

GitLab dan GitHub menawarkan tiga metode penggabungan untuk Merge Request. Pilihan tergantung pada kebijakan tim dan kebersihan riwayat yang diinginkan. Merge Commit — membuat commit penggabungan terpisah, mempertahankan seluruh riwayat cabang fitur. Squash — menggabungkan semua commit cabang menjadi satu commit di cabang target. Fast-Forward — menerapkan commit secara linear tanpa commit penggabungan.

Menurut GitLab Docs, 2025, Squash lebih disukai dalam proyek dengan kepadatan commit tinggi (20+ commit dalam satu cabang fitur). Fast-Forward wajib untuk Trunk-Based Development. Merge Commit digunakan dalam Git Flow untuk mempertahankan semantik percabangan.

• Merge Commit — mempertahankan riwayat, membuat commit penggabungan, cocok untuk Git Flow
• Squash — menggabungkan semua commit menjadi satu, riwayat bersih, commit perantara hilang
• Fast-Forward — riwayat linear tanpa commit penggabungan, wajib di TBD

Praktik terbaik: cara menulis MR yang baik

Merge Request (MR) yang berkualitas mempersingkat waktu review dan mengurangi jumlah kesalahan. Aturan pertama — satu MR menyelesaikan satu tugas. Jika perubahan memengaruhi beberapa fitur yang tidak terkait, perubahan tersebut harus dipecah menjadi MR terpisah. Kedua — judul MR harus informatif: “Add OAuth2 authentication with Google provider” alih-alih “Fix stuff” atau “Update code”.

Menurut Google Engineering Practices, 2024, MR yang baik berisi deskripsi konteks: mengapa perubahan diperlukan, bagaimana diuji, apa risikonya. Ukuran MR tidak boleh melebihi 400 baris perubahan. Jika volume lebih besar — tugas harus didekomposisi menjadi subtugas. Untuk dokumentasi dan pengujian, pengecualian diperbolehkan, tetapi dengan penjelasan.

Merge Request (MR) harus menyertakan pengujian otomatis untuk fungsionalitas baru. Di GitLab, kebijakan Coverage Check dapat dikonfigurasi — MR secara otomatis diblokir jika cakupan kode turun di bawah ambang batas (misalnya, 80%). Ini memastikan bahwa fungsionalitas baru tidak menurunkan kualitas proyek secara keseluruhan.

• Satu MR — satu tugas: dekomposisi perubahan besar menjadi beberapa MR kecil
• Deskripsi dengan templat: gunakan .gitlab/merge_request_templates untuk keseragaman
• Ukuran hingga 400 baris: MR besar diperiksa lebih lambat dan dengan lebih banyak kesalahan
• Pengujian wajib: fitur baru harus dicakup oleh pengujian unit

Templat deskripsi MR

GitLab mendukung templat Merge Request melalui file .gitlab/merge_request_templates/. Templat berisi bagian: apa yang dilakukan, cara menguji, tugas terkait, dan daftar periksa. Penggunaan templat mempercepat pembuatan MR dan memastikan pengembang tidak lupa mencantumkan informasi penting. Dalam deskripsi MR, issue terkait (Closes #N) wajib dicantumkan untuk penutupan otomatis tugas saat penggabungan.