Apa Itu Pull Request? Cara Kerja dan Cara Membuat PR yang Baik

Kalau kamu sudah terbiasa dengan Git, istilah berikutnya yang akan sering kamu temui adalah Pull Request atau PR. Di hampir semua tim engineering yang memakai GitHub, kode tidak langsung masuk ke branch utama — ia masuk lewat Pull Request.

Artikel ini menjelaskan apa itu Pull Request, bagaimana alurnya, dan kebiasaan membuat PR yang mudah di-review.

Pengertian Pull Request

Pull Request adalah permintaan untuk menggabungkan perubahan dari satu branch ke branch lain — biasanya dari branch fitur ke main. Tapi PR lebih dari sekadar tombol merge. PR adalah ruang diskusi tempat perubahan kode:

• ditampilkan baris per baris (diff),
• dijelaskan oleh pembuatnya,
• diperiksa oleh pengecekan otomatis (test, lint, build),
• di-review dan dikomentari oleh rekan tim,
• diperbaiki sampai layak, lalu di-merge.

Di GitLab, konsep yang sama disebut Merge Request.

Istilah "pull" berasal dari sudut pandang pemilik repository: kamu meminta mereka menarik perubahanmu ke branch mereka.

Kenapa tim memakai Pull Request?

• Menjaga kualitas. Setiap perubahan dilihat setidaknya oleh satu orang lain sebelum masuk.
• Berbagi pengetahuan. Reviewer jadi tahu bagian kode yang berubah, dan pembuat PR belajar dari masukan.
• Jejak keputusan. Diskusi di PR menjelaskan kenapa sebuah perubahan dibuat — berguna berbulan-bulan kemudian.
• Otomatisasi. PR menjadi pemicu CI yang menjalankan test dan pengecekan lain.

Alur Pull Request dari awal sampai merge

Berikut alur yang umum dipakai. Kalau perintah Git di bawah belum familiar, baca dulu Belajar Git untuk Pemula.

1. Buat branch dari main terbaru

git switch main
git pull
git switch -c feature/filter-pesanan

2. Kerjakan perubahan dan commit bertahap

git add .
git commit -m "Tambah filter status di daftar pesanan"

3. Push branch ke GitHub

git push -u origin feature/filter-pesanan

4. Buka Pull Request

Di GitHub, buka repository lalu pilih Compare & pull request. Pastikan arahnya benar: base main, compare branch fiturmu. Isi judul dan deskripsi.

5. Tunggu pengecekan otomatis

Kalau repository punya CI, test dan pengecekan lain akan berjalan. Perbaiki dulu kalau ada yang gagal — reviewer biasanya tidak akan mereview PR yang CI-nya merah.

6. Review dan diskusi

Reviewer memberi komentar: pertanyaan, saran, atau permintaan perubahan. Status review di GitHub umumnya berupa Comment, Approve, atau Request changes.

7. Perbaiki dan push ulang

Kamu tidak perlu membuka PR baru. Cukup commit perbaikan di branch yang sama dan push — PR akan otomatis ter-update.

8. Merge

Setelah disetujui dan semua pengecekan lolos, PR di-merge ke main. Branch fitur biasanya dihapus setelahnya.

Anatomi Pull Request yang baik

Judul yang menjelaskan hasil

Judul PR sebaiknya menjelaskan apa yang berubah dari sudut pandang hasil, bukan proses.

• Kurang jelas: Update order page
• Lebih jelas: Tambah filter status pada halaman daftar pesanan

Deskripsi yang menjawab tiga pertanyaan

1. Apa yang berubah?
2. Kenapa perubahan ini dibutuhkan? (tautkan ke tiket/PRD kalau ada)
3. Bagaimana cara menguji atau memverifikasinya?

Contoh deskripsi singkat:

## Apa
Menambahkan filter status (menunggu, dibayar, dikirim) di halaman daftar pesanan.

## Kenapa
Tim operasional perlu melihat pesanan yang belum dikirim tanpa scroll seluruh daftar.

## Cara menguji
1. Buka /orders
2. Pilih status "dibayar" — hanya pesanan berstatus dibayar yang tampil
3. Kosongkan filter — semua pesanan tampil kembali

Ukuran yang wajar

PR yang terlalu besar sulit di-review dengan teliti. Reviewer cenderung melewatkan detail saat berhadapan dengan ratusan baris perubahan sekaligus. Kalau fiturnya besar, pecah menjadi beberapa PR yang masing-masing bisa berdiri sendiri.

Fokus pada satu tujuan

Jangan campur perbaikan bug, refactor, dan fitur baru dalam satu PR. Kalau menemukan hal lain yang perlu diperbaiki, buat PR terpisah.

Review diri sendiri dulu

Sebelum meminta review, buka tab Files changed dan baca perubahanmu seolah-olah kamu reviewer. Sering kali kamu akan menemukan sisa console.log, kode yang dikomentari, atau nama variabel yang kurang jelas.

Kesalahan umum saat membuat Pull Request

• Deskripsi kosong. Reviewer terpaksa menebak konteksnya.
• Membuka PR saat pekerjaan belum selesai tanpa memberi tanda. Gunakan fitur Draft Pull Request kalau ingin berbagi progres.
• Mengabaikan CI yang gagal. Perbaiki dulu sebelum meminta review.
• Defensif terhadap komentar. Komentar review menilai kode, bukan dirimu. Cara menanggapinya dibahas di Code Review untuk Pemula.
• Force push sembarangan setelah review dimulai. Ini bisa menghapus konteks komentar. Ikuti konvensi tim.

Bagaimana cara berlatih Pull Request?

Pull Request paling mudah dipelajari dengan melakukannya berulang kali:

• Biasakan membuka PR ke repository sendiri untuk setiap fitur, lalu review sebelum merge.
• Berkontribusi ke proyek open source yang menerima kontributor baru.
• Ikut program yang menjadikan Pull Request dan review sebagai bagian inti dari latihannya.

Kesimpulan

Pull Request adalah cara tim engineering memasukkan perubahan kode secara aman: perubahan dijelaskan, diperiksa otomatis, di-review, diperbaiki, lalu di-merge. PR yang baik punya judul yang jelas, deskripsi yang menjawab apa–kenapa–bagaimana, ukuran yang wajar, dan fokus pada satu tujuan.

Di simulasi kerja software engineer KodingCamp, setiap misi dikumpulkan lewat Pull Request dan di-review oleh Tech Lead AI — jadi kamu berlatih alur ini dalam kondisi yang mendekati kerja nyata. Lihat juga gambaran alur lengkapnya di Software Engineer Workflow.