Pull Request: apa itu, proses pembuatan dan code review

Apa itu Pull Request?

Pull Request (PR) — adalah permintaan formal untuk memasukkan perubahan dari satu cabang ke cabang lain dalam sistem kontrol versi terdistribusi. PR adalah elemen utama pengembangan kolaboratif di platform GitHub, GitLab, dan Bitbucket, menggabungkan diskusi kode, pengujian otomatis, dan proses persetujuan perubahan.

Nama “Pull Request” mencerminkan esensi operasi: pengembang meminta (request) pemilik repositori untuk “menarik” (pull) perubahannya. Istilah ini diperkenalkan oleh GitHub pada tahun 2008 — sebelumnya mekanisme serupa ada dalam bentuk patch dan merge request (istilah GitLab). Saat ini PR adalah standar de facto untuk kerja tim dengan Git.

Menurut GitHub Octoverse, 2025, 89% proyek open-source memerlukan pembuatan PR untuk melakukan perubahan. Dalam pengembangan perusahaan, angka ini mencapai 95%. PR telah menjadi tidak hanya alat teknis, tetapi bagian dari budaya pengembangan: melalui PR terjadi transfer pengetahuan, deteksi bug, dan koordinasi keputusan arsitektur.

Komponen Pull Request

PR tipikal terdiri dari judul, deskripsi, daftar file yang diubah (diff), komentar peninjau, dan status pemeriksaan CI. Setiap PR terikat pada cabang sumber dan target tertentu, dan setelah digabungkan dapat dihapus secara otomatis.

Cara Membuat Pull Request

Membuat PR dimulai dengan mempublikasikan cabang fitur ke repositori jarak jauh. Setelah push, pengembang membuka PR melalui antarmuka platform atau melalui CLI (gh, glab). Mari kita lihat prosesnya dengan contoh GitHub.

Push cabang dan membuka PR

Langkah pertama — push cabang fitur ke repositori jarak jauh dan buat Pull Request melalui antarmuka web atau baris perintah.

# Buat dan push cabang fitur
git checkout -b feature/biometric-auth
git add src/auth/
git commit -m "feat: add biometric authentication"
git push -u origin feature/biometric-auth

# Buat PR melalui GitHub CLI
gh pr create --title "feat: add biometric authentication" \
  --body "Implements fingerprint and face recognition login.
  Closes #142" \
  --base develop

Setelah PR dibuat, GitHub secara otomatis menjalankan pipeline CI (GitHub Actions), memeriksa adanya konflik dengan cabang target, dan mengundang peninjau. Templat deskripsi PR dapat dikonfigurasi melalui .github/PULL_REQUEST_TEMPLATE.md agar semua PR berisi bagian wajib: tujuan, perubahan, pengujian, tugas terkait.

Deskripsi dan pelabelan

Deskripsi PR yang berkualitas mencakup: tautan ke tugas (issue/ticket), deskripsi singkat perubahan, instruksi pengujian, dan daftar perubahan terkait. Label (bug, feature, refactoring) membantu mengkategorikan PR, dan assignee serta reviewer ditetapkan secara otomatis melalui CODEOWNERS.

# Tetapkan peninjau melalui CODEOWNERS (file di root repositori)
# Contoh .github/CODEOWNERS:
# src/auth/ @team-auth @senior-dev
# src/api/ @team-backend
# *.kt @kotlin-team

# Buat PR dengan penetapan peninjau melalui gh cli
gh pr create --reviewer "team-auth" --label "feature"

CODEOWNERS — mekanisme standar GitHub/GitLab untuk penetapan reviewer secara otomatis berdasarkan file yang diubah. Misalnya, perubahan apa pun di direktori src/auth/ secara otomatis menetapkan team-auth dan senior-dev sebagai reviewer. Ini mempercepat proses dan memastikan orang yang tepat melihat PR.

Memperbarui PR setelah review

Setelah menerima komentar peninjau, pengembang melakukan perbaikan di cabang fitur yang sama dan melakukan push commit baru — PR diperbarui secara otomatis. Penting untuk tidak menulis ulang riwayat (rebase) di cabang fitur yang sudah dipublikasikan jika PR sudah terbuka, karena ini akan merusak tautan ke commit tertentu di komentar.

# Lakukan perubahan sesuai komentar peninjau
git checkout feature/biometric-auth
# perbaiki kode
git commit -m "fix: handle biometric timeout per review"
git push

# PR akan diperbarui secara otomatis
# Setelah disetujui — gabungkan PR melalui antarmuka GitHub

Proses Code Review

Code review — elemen utama Pull Request. Peninjau memeriksa perubahan dari segi kebenaran, gaya kode, keamanan, dan kesesuaian arsitektur. Review berkualitas tidak hanya mencegah bug, tetapi juga menyebarkan pengetahuan tentang basis kode di dalam tim.

Google Engineering Practices (2025) merekomendasikan prinsip code review berikut: peninjau harus memahami konteks perubahan, memberikan rekomendasi spesifik daripada komentar umum, memisahkan komentar teknis dan gaya. Waktu review tidak boleh melebihi 24 jam sejak PR dibuat.

Untuk pengembangan aplikasi mobile, code review mencakup pemeriksaan spesifik: kompatibilitas dengan targetSdk, kebenaran penanganan lifecycle (Android) / view lifecycle (iOS), tidak adanya kebocoran memori (LeakCanary, Instruments), dukungan tema gelap dan lokalisasi. Pemeriksaan ini dapat diotomatisasi melalui linter dan Detekt/ktlint.

Jenis komentar

Platform PR mendukung tiga jenis komentar: umum (untuk seluruh PR), baris (untuk baris kode tertentu), dan saran (suggestions dengan kode pengganti). Saran memungkinkan penerapan perubahan dengan satu klik, yang mempercepat proses dan mengurangi jumlah iterasi.

Setelah semua komentar diselesaikan dan pemeriksaan CI lulus, peninjau mengirim persetujuan (Approved). PR dapat digabungkan. GitHub dan GitLab mendukung aturan perlindungan cabang (branch protection rules): jumlah persetujuan wajib, pemeriksaan CI wajib, larangan push ke main tanpa PR. Untuk proyek mobile, branch protection juga mencakup pemeriksaan build: PR tidak dapat digabungkan jika aplikasi tidak terbangun (gradle build failed / xcodebuild failed).

Penyelesaian konflik di PR

Konflik merge di Pull Request adalah situasi normal dalam kerja tim yang aktif. Platform menawarkan penyelesaian konflik melalui antarmuka web (untuk konflik sederhana) atau merekomendasikan penyelesaian lokal. GitHub Actions secara otomatis memeriksa kemampuan penggabungan setiap push ke cabang fitur dan menandai PR sebagai conflict jika penggabungan tidak memungkinkan.

Praktik Terbaik Pull Request

Pull Request yang efektif mempercepat code review dan mengurangi jumlah bug. Penelitian SmartBear (2025) menunjukkan bahwa PR hingga 200 baris kode menerima 2 kali lebih banyak komentar bermakna daripada PR dengan lebih dari 1000 baris, dan waktu review berkurang 3 kali lipat.

• PR kecil — ukuran optimal 100-300 baris. Bagi PR besar menjadi bagian logis: setiap PR menyelesaikan satu tugas. Ini menyederhanakan review dan mengurangi kemungkinan konflik
• Deskripsi jelas — judul sesuai Conventional Commits (feat:, fix:, refactor:), isi PR berisi “apa dan mengapa”, bukan “bagaimana” (kode berbicara sendiri). Templat: tujuan → perubahan → pengujian → masalah terkait
• Umpan balik cepat — review dalam 24 jam. Jika PR menunggu lebih dari sehari — tim kehilangan konteks, jumlah konflik saat merge meningkat
• Otomatisasi — linter, formatter, dan tes harus berjalan otomatis saat PR dibuat. Jangan izinkan penggabungan PR dengan pemeriksaan CI merah
• Draft PR — gunakan untuk diskusi awal tentang arsitektur. Draft PR tidak memerlukan review dan tidak dapat digabungkan, tetapi memungkinkan untuk menunjukkan kode kepada kolega di tahap awal

Praktik tambahan: jangan buat PR Jumat malam (tidak ada yang akan review hingga Senin), minta review dari 1-2 orang (lebih banyak memperlambat proses tanpa meningkatkan kualitas), gunakan squash merge untuk mengompresi riwayat sebelum penggabungan. Untuk proyek mobile, disarankan juga menambahkan tautan ke build pengujian (Firebase App Distribution / TestFlight) di deskripsi PR agar peninjau dapat memeriksa perubahan di aplikasi yang berfungsi.

Pull Request di Berbagai Platform

Platform utama untuk bekerja dengan Pull Request adalah GitHub, GitLab, dan Bitbucket. Meskipun konsepnya sama, masing-masing memiliki fitur yang perlu dipertimbangkan saat memilih alat untuk tim.

GitHub — platform paling populer dengan komunitas terbesar, Actions untuk CI/CD dan ekosistem aplikasi yang luas (GitHub Marketplace). GitLab menonjol dengan CI/CD bawaan dan kemungkinan penerapan self-hosted penuh. Bitbucket terintegrasi erat dengan Jira dan ekosistem Atlassian, populer di lingkungan perusahaan.

Untuk pengembangan aplikasi mobile, pilihan platform sering ditentukan oleh kemampuan CI/CD: GitHub Actions mendukung runner macOS untuk membangun iOS, GitLab memiliki runner bawaan untuk iOS/Android, Bitbucket terintegrasi baik dengan Firebase Test Lab. Terlepas dari platform, proses PR tetap sama: cabang → review → CI → merge.