Pull Request: Membuat Usulan Perubahan

Apa itu Pull Request, dan kenapa tidak langsung push ke main?

Pull Request (PR) adalah usulan: "tolong tarik perubahan dari branch-ku ke branch utama". Tapi ia bukan sekadar tombol merge. PR adalah ruang diskusi tempat kode di-review, test otomatis dijalankan, dan perubahan didebatkan SEBELUM digabung.

Kenapa tidak langsung push ke main? Karena main adalah "etalase" yang harus selalu jalan. Satu commit ceroboh yang di-push langsung bisa merusak kode semua orang tanpa ada yang memeriksa. PR memasang gerbang: setiap perubahan harus lewat pemeriksaan dulu.

Contoh 1: dari branch lokal sampai PR terbuka

Kerjakan fitur di branch terpisah, jangan di main:

git switch -c fitur-notifikasi
# ... ngoding ...
git commit -m "Tambah notifikasi email saat pesanan dibuat"
git push -u origin fitur-notifikasi

GitHub memberimu link siap klik. Buka di browser, klik banner kuning "Compare & pull request", lalu isi dengan serius:

1. Judul jelas: "Tambah notifikasi email saat pesanan dibuat" (bukan "update" atau "fix").
2. Deskripsi: apa yang diubah, KENAPA diubah, dan cara mengetesnya.
3. Reviewer: pilih teman yang diminta me-review.
4. Link issue: tulis Closes #42 supaya issue otomatis tertutup saat PR di-merge.

Contoh 2: membuat PR langsung dari terminal

Kalau kamu sudah install GitHub CLI (gh), tidak perlu buka browser:

gh pr create --title "Tambah notifikasi email saat pesanan dibuat" --body "Closes #42. Cara tes: buat pesanan baru, cek inbox."

PR nomor 17 langsung jadi, praktis kalau sudah hafal polanya.

Anatomi halaman PR

• Conversation: diskusi dan riwayat aktivitas PR.
• Commits: daftar commit di dalam PR (bisa banyak, tidak apa-apa).
• Files changed: diff yang akan di-review baris per baris.
• Checks: status CI, test lolos atau gagal. PR dengan checks merah biasanya tidak boleh di-merge.

Draft PR untuk kerja setengah jadi

Butuh feedback arah tapi kode belum siap di-merge? Buka sebagai Draft PR. Ia tidak bisa di-merge sampai kamu tandai "Ready for review". Cocok untuk bertanya "apakah pendekatanku sudah benar?" sebelum terlanjur ngoding 3 hari ke arah yang salah.

Catatan teknis: PR di GitHub terikat pada perbandingan dua branch (base vs compare). Kamu boleh push lagi ke branch sumber setelah PR dibuka, dan PR otomatis ter-update. Tapi jangan ganti nama branch sumber setelah PR dibuka, karena itu memutus tautannya.

Kapan membuat PR?

Untuk setiap perubahan yang masuk ke branch bersama (main/develop), sekecil apa pun. Bahkan perbaikan typo satu baris lebih baik lewat PR: ada jejak review dan CI tetap jalan. Satu-satunya pengecualian adalah repo pribadi solo tanpa CI, di mana direct push masih wajar.

Kesalahan umum pemula

SALAH: judul PR "update" dengan deskripsi kosong.

Reviewer membuka PR-mu dan tidak tahu harus memeriksa apa. Ia harus menebak-nebak dari diff, akhirnya review-nya asal-asalan atau malah tidak di-review sama sekali.

BENAR: judul spesifik + deskripsi berisi konteks dan cara tes.

Judul yang baik menjelaskan perubahan dalam satu baris. Deskripsi menjawab tiga hal: apa yang diubah, kenapa (masalah apa yang diselesaikan), dan bagaimana cara mengetesnya. Reviewer yang paham konteks akan memberi review 10x lebih berguna.

Kesalahan kedua: satu PR raksasa berisi 5 fitur sekaligus. Reviewer kewalahan, review-nya asal lewat, bug lolos. Pecah jadi beberapa PR kecil; masing-masing gampang di-review dan gampang di-revert kalau bermasalah.