Pull Request dan Cara Kolaborasi di GitHub

Di episode sebelumnya kamu belajar branch dan merge di komputermu sendiri. Itu seperti latihan masak di dapur sendiri. Sekarang saatnya buka restoran: masakanmu akan dicicipi orang lain sebelum disajikan ke pelanggan. Itulah pull request, mekanisme kolaborasi paling penting di dunia open source dan tim profesional. Kalau Git adalah alatnya, pull request adalah budayanya.

Artikel ini episode ke-6 dari series Git dan GitHub. Kita bahas alur pull request dari bikin sampai merge, tiga cara menggabungkan yang dipakai tim profesional, dan etika review kode yang membedakan kontributor disukai dari yang dihindari.

Kenapa Pull Request Ada, Padahal Bisa Langsung Push?

Secara teknis kamu memang bisa push langsung ke main kalau punya akses. Tapi tim profesional melarang itu, dan alasannya masuk akal kalau dipikir. main adalah kode yang dipercaya pelanggan. Setiap perubahan yang masuk harus melewati minimal sepasang mata kedua. Pull request adalah ruang formal untuk itu: tempat perubahan diusulkan, didiskusikan, diuji otomatis, baru digabung.

Analoginya seperti dapur restoran. Koki tidak langsung menyajikan masakan eksperimen ke tamu. Dia taruh di meja tasting, sous-chef cicipi, kasih masukan, mungkin minta tambah garam. Baru setelah oke, hidangan masuk menu. Pull request adalah meja tasting itu. Tanpa meja ini, satu koki yang lagi bad mood bisa merusak reputasi seluruh restoran dalam satu push.

Luruskan Dulu: Pull Request Bukan Cuma Buat Proyek Raksasa

Salah kaprah pertama: PR cuma relevan buat open source besar seperti Linux atau React. Faktanya, tim berisi dua orang pun pakai PR. Bahkan programmer solo yang serius pakai PR untuk dirinya sendiri: bikin branch, buka PR, baca ulang diff-nya keesokan hari dengan mata segar, baru merge. Itu cara murah dapat "reviewer" gratis, yaitu dirimu yang sudah tidur cukup.

Salah kaprah kedua: tombol merge diklik berarti kode sudah sempurna. Merge artinya "cukup baik untuk lanjut", bukan "sempurna". Review yang bagus fokus ke hal yang penting: apakah logikanya benar, apakah ada bug nyata, apakah bisa dipahami orang lain. Review yang buruk ribut soal selera, misalnya debat 20 komentar soal nama variabel. Bedakan keduanya dan kamu akan jadi reviewer yang disukai.

Anatomi Pull Request: Base, Head, dan Diff

Setiap PR punya tiga komponen yang wajib kamu pahami. Base branch adalah tujuan, biasanya main, tempat perubahan akan mendarat. Head branch adalah asal, branch tempat kamu kerja, misalnya fitur-login. Diff adalah daftar semua perbedaan antara keduanya, baris per baris, yang akan dibaca reviewer.

Alur standarnya: push branch-mu ke GitHub, buka halaman repo, klik tombol Compare and pull request, tulis judul dan deskripsi yang menjelaskan kenapa perubahan ini dibuat (bukan cuma apa yang diubah, itu sudah kelihatan di diff), lalu tunggu review. Deskripsi PR yang baik menjawab tiga pertanyaan: masalah apa yang diselesaikan, gimana cara menyelesaikannya, dan gimana cara mengujinya.

Tiga Cara Merge: Pilih Sesuai Kebutuhan Tim

Di GitHub ada tiga metode menggabungkan PR, dan pemilik repo bisa mengaktifkan semuanya atau membatasi. Memahami bedanya penting karena ini memengaruhi kerapian riwayat proyek.

Create a merge commit mempertahankan semua commit dari branch-mu apa adanya, plus satu merge commit sebagai tanda penggabungan. Riwayatnya jujur dan lengkap, tapi bisa ramai kalau branch-mu berisi 30 commit "fix typo" dan "coba lagi". Cocok untuk fitur besar yang sejarahnya memang perlu dilacak.

Squash and merge memampatkan semua commit-mu jadi satu commit rapi sebelum digabung. Riwayat main jadi bersih: satu fitur sama dengan satu commit. Ini favorit banyak tim karena git log tetap enak dibaca. Kekurangannya, detail perjalananmu hilang, jadi pastikan pesan commit hasil squash-nya deskriptif.

Rebase and merge menempel ulang commit-mu satu per satu di ujung main tanpa merge commit. Hasilnya riwayat linear seperti garis lurus, tidak ada percabangan. Tapi setiap commit ditulis ulang dengan hash baru, jadi jangan pakai ini di branch yang dipakai bareng orang lain.

Etika Review: Dikritik Itu Hadiah, Memberi Kritik Itu Seni

Kolaborasi bukan cuma soal tombol, tapi soal manusia. Beberapa aturan tak tertulis yang berlaku di hampir semua tim. Saat meminta review: bikin PR sekecil mungkin. PR 50 baris direview dalam 10 menit dengan teliti. PR 2000 baris direview dalam 10 detik dengan pasrah. Kalau perubahanmu besar, pecah jadi beberapa PR berurutan.

Saat memberi review: komentari kode, bukan orangnya. "Fungsi ini bisa disederhanakan pakai map" jauh lebih baik dari "kamu nulisnya berantakan". Bedakan juga mana yang wajib diperbaiki dan mana yang sekadar saran. Banyak tim pakai konvensi: komentar diawali "nit:" untuk hal kecil yang boleh diabaikan.

Saat menerima review: jangan defensif. Reviewer yang menemukan bug di kodemu baru saja menyelamatkanmu dari bug yang sama di production, tempat biayanya seratus kali lipat. Ucapkan terima kasih, perbaiki, dan kalau tidak setuju, jelaskan alasanmu dengan data, bukan emosi.

Checklist Review: Yang Dicek Reviewer Bagus

Supaya review-mu tajam dan tidak sekadar "LGTM" (looks good to me), pakai checklist ini setiap kali membuka tab Files changed. Pertama, kebenaran logika: apakah kode ini melakukan yang diklaim deskripsi PR? Coba telusuri satu skenario dari input sampai output di kepalamu. Kedua, edge case: apa yang terjadi kalau inputnya kosong, nol, atau sangat besar? Kebanyakan bug sembunyi di sini. Ketiga, keterbacaan: bisakah kamu memahami fungsi ini tanpa bertanya ke penulisnya? Kalau butuh 10 menit untuk paham 20 baris, kodenya perlu disederhanakan atau dikomentari.

Keempat, efek samping: apakah perubahan ini memengaruhi bagian lain yang tidak disebut di deskripsi? Cari pemanggilan fungsi yang diubah di seluruh repo. Kelima, tes: apakah ada cara membuktikan perubahan ini bekerja? PR tanpa cara verifikasi memaksa reviewer percaya begitu saja, dan kepercayaan buta adalah musuh kualitas.

Kamu tidak harus menemukan masalah di setiap review. Checklist ini bukan untuk mencari-cari kesalahan, tapi untuk memastikan tidak ada yang terlewat. Review yang baik kadang berakhir dengan "sudah saya cek semua, aman", dan itu tetap review yang berharga.

Fork: Cara Berkontribusi ke Repo Orang Lain

Alur di atas berlaku kalau kamu punya akses tulis ke repo. Kalau mau kontribusi ke proyek open source milik orang lain, kamu tidak punya akses itu. Solusinya: fork. Fork adalah salinan repo ke akunmu sendiri. Kamu bebas ngoprek di fork-mu, lalu buka pull request dari fork-mu ke repo aslinya. Pemilik repo tinggal review dan merge kalau cocok. Begitulah jutaan kontribusi open source terjadi setiap hari, termasuk perbaikan dokumentasi satu baris dari pemula yang baru belajar kemarin.

Latihan: Jadi Reviewer Untuk Dirimu Sendiri

Latihan kali ini melatih otot yang jarang dilatih pemula: membaca kode orang lain, walau orang lain itu dirimu sendiri.

1. Di repo latihanmu, bikin branch baru tambah-fitur-kecil. Tambahkan satu fungsi sederhana, misalnya fungsi menghitung diskon, lengkap dengan contoh pemakaiannya.
2. Push branch dan buka pull request ke main. Tulis deskripsi yang menjawab: masalah apa, gimana solusinya, gimana cara mengujinya.
3. Jangan langsung merge. Diamkan satu hari. Besok, buka tab Files changed dan baca diff-mu seolah itu kode orang lain. Catat minimal 3 hal yang bisa diperbaiki: nama yang membingungkan, komentar yang kurang, atau edge case yang belum ditangani.
4. Perbaiki temuanmu, push lagi, perhatikan PR-nya terupdate sendiri. Baru merge pakai squash and merge, dan tulis pesan commit yang rapi.
5. Bonus: minta satu teman untuk me-review PR latihanmu, atau review PR latihan temanmu. Rasakan bedanya dikritik dan mengkritik.

Kolaborasi sudah di tangan. Tapi repo yang dikunjungi orang tanpa penjelasan ibarat warung tanpa papan nama. Di episode berikutnya, Cara Nulis README dan Gitignore yang Rapi, kita rapikan etalase repo-mu: README yang bikin orang betah, dan .gitignore yang menjaga file rahasia tidak bocor ke publik.