Belajar Git - Pull Request (PR) & Code Review di GitHub

#Pendahuluan

Di episode 10 kita membahas pola workflow kolaborasi: Centralized Workflow, Feature Branch Workflow, Gitflow, hingga Trunk-Based Development. Jika kalian perhatikan, hampir semua pola modern bermuara pada satu pintu gerbang yang sama sebelum kode menyentuh main — yaitu Pull Request (PR). PR bukan sekadar tombol "gabungkan kode", melainkan ruang diskusi, pemeriksaan kualitas, dan dokumentasi keputusan yang tersimpan permanen di repository.

Mengapa ini penting di dunia nyata? Banyak tim menetapkan aturan "tidak ada kode yang masuk ke main tanpa PR yang disetujui". Di perusahaan besar, PR menjadi tempat code review — menemukan bug sebelum produksi, bukan sesudahnya. PR yang ditulis baik juga menjadi jembatan komunikasi: apa yang diubah, mengapa diubah, dan bagaimana mengujinya. Episode ini membahas cara membuat PR, menulis deskripsi yang informatif, melakukan code review, dan memilih strategi merge yang tepat.

#Apa itu Pull Request?

Pull Request adalah permintaan untuk menggabungkan sebuah branch (sumber) ke branch lain (tujuan). Ia mengemas semua yang dibutuhkan reviewer dalam satu tempat:

Diff — seluruh perubahan kode yang ditawarkan.
Commit — daftar commit yang menjadi bagian PR.
Deskripsi — penjelasan konteks, alasan, dan cara menguji.
Komentar & review — umpan balik dari anggota tim.
Status checks — hasil CI/CD yang harus hijau sebelum merge.

PR menambahkan lapisan yang tidak dimiliki git merge biasa: keputusan manusia dan mesin sebelum kode digabungkan. Git menyediakan mekanisme menggabungkan; GitHub menyediakan mekanisme persetujuan.

#Membuat Pull Request dari GitHub UI

Cara paling umum adalah lewat UI. Alurnya dimulai dari push branch ke remote:

Push branch fitur ke remote

git switch -c feat/login
git add .
git commit -m "feat: tambah halaman login"
git push -u origin feat/login

Setelah push, GitHub menampilkan banner "Compare & pull request" di halaman repository. Klik tombol itu, lalu perhatikan tiga hal:

Base branch — cabang tujuan (biasanya main).
Compare branch — cabang sumber (misal feat/login).
Title & description — diisi sesuai template.

Setelah yakin, klik Create pull request. PR kini punya nomor unik (misal #42) dan bisa dibagikan ke tim.

Tip

Periksa kembali base branch sebelum membuat PR. Error klasik adalah PR yang ditujukan ke branch yang salah, misalnya staging yang inginnya main — akibatnya kode mendarat di tempat yang tidak semestinya.

#Membuat PR dengan GitHub CLI

Praktisi CLI bisa melakukan semuanya tanpa membuka browser. Pastikan sudah login dengan gh auth login (dibahas di episode 0), lalu gunakan gh pr create:

Membuat PR dari terminal

gh pr create \
  --base main \
  --head feat/login \
  --title "feat: tambah halaman login" \
  --body "Menambahkan autentikasi pengguna dengan token JWT."

Beberapa perintah gh pr yang wajib kalian hafal:

gh pr create --fill — mengisi title dan body otomatis dari commit.
gh pr view — melihat detail PR.
gh pr checkout — pindah ke branch PR untuk mengetes langsung.
gh pr merge — merge PR ketika sudah disetujui.

Cek status PR dari terminal

gh pr list --state open
gh pr view --web
gh pr merge 42 --squash

#Menulis Deskripsi PR yang Informatif

Deskripsi yang baik menjawab pertanyaan reviewer sebelum mereka bertanya. Template yang lazim di tim profesional:

Template deskripsi PR

## Apa yang berubah?
Menambahkan autentikasi login dengan JWT di sisi API.
 
## Mengapa?
Menutup celah autentikasi yang sebelumnya tidak ada.
 
## Screenshot
![Tampilan halaman login](/static/demo/login.png)
 
## Cara menguji
1. Jalankan `bun run dev`
2. Login dengan akun dummy yang sudah dibuat

Screenshot dan video mempercepat review secara drastis. Di browser, kalian bisa langsung menempel gambar dari clipboard ke textarea deskripsi — GitHub mengunggahnya otomatis. Untuk perubahan visual, rekam GIF atau video singkat yang menunjukkan alur sebelum dan sesudah.

#Proses Code Review

Saat PR dibuat, reviewer menilai kode di tab Files changed. GitHub menyediakan tiga bentuk umpan balik:

Inline comment — komentar yang menempel pada baris kode tertentu.
Approve — menyetujui PR, siap merge.
Request changes — meminta revisi sebelum kode boleh masuk.

Komentar inline adalah alat utama code review: kalian bisa menyorot baris tertentu, menulis pertanyaan atau saran, lalu memakai tombol Start a review supaya komentar terkirim sekaligus. Dari terminal, gunakan gh pr review:

Review PR via CLI

gh pr review 42 --approve
gh pr review 42 --request-changes --body "Tolong tangani kasus token yang sudah kedaluwarsa."
gh pr review 42 --comment --body "Terima kasih, saya tambahkan test besok."

Tip

Code review yang baik menjelaskan kenapa, bukan hanya apa. Daripada menulis "ganti ini", tulis "sebaiknya pakai flag atomic karena dua baris ini harus ter-commit bersama". Fokus pada behavior dan keamanan, bukan selera pribadi.

Setelah reviewer Request changes, penulis memperbaiki kode, push commit baru ke branch yang sama, dan PR otomatis ter-update. Proses berulang sampai disetujui.

#Strategi Merge PR

Saat PR disetujui, tiba waktunya memilih cara menggabungkan. GitHub menawarkan tiga strategi:

Strategi	Cara Kerja	Efek pada History	Kapan Dipakai
Create a Merge Commit	Semua commit branch digabung plus satu merge commit	History lengkap dengan percabangan	Perlu jejak kontribusi per-commit
Squash and Merge	Semua commit digabung menjadi satu	Satu commit bersih per fitur	Paling direkomendasikan
Rebase and Merge	Commit diterapkan satu per satu secara linear	History linear tanpa merge commit	Ingin linear namun per-commit dipertahankan

Squash and Merge adalah rekomendasi default untuk kebanyakan tim. Alasannya: history menjadi rapi — satu fitur satu commit, mudah dibaca, mudah di-bisect (episode 17), dan mudah di-revert satu fitur sekaligus (episode 14). Commit kecil seperti "wip", "fix typo", dan "update" selama pengembangan tidak perlu terlihat di main.

Membandingkan hasil strategi merge

git log --oneline --graph --all -8
git log --oneline --first-parent

Baris pertama menunjukkan grafis history setelah merge; baris kedua menampilkan hanya commit utama — dengan squash, hasilnya deretan commit fitur yang linear dan mudah diikuti.

#Penutup

Episode ini membawa kalian dari sekadar push kode menjadi kolaborator profesional: konsep Pull Request sebagai gerbang kualitas, pembuatan PR dari GitHub UI dan gh pr create, deskripsi PR yang informatif dengan screenshot, proses code review dengan inline comments dan request changes, serta tiga strategi merge beserta rekomendasi Squash and Merge.

Poin yang harus kalian bawa:

PR mengemas diff, commit, deskripsi, review, dan status checks dalam satu tempat.
Selalu periksa base branch sebelum membuat PR.
Deskripsi yang baik menjawab apa, mengapa, dan cara menguji.
Inline comments adalah alat utama code review; request changes memblokir merge.
Squash and Merge menjaga history tetap rapi dan direkomendasikan secara default.

PR yang baik membuka pertanyaan besar berikutnya: apa yang harus dikerjakan? Di episode 12 kita membahas GitHub Issues, Labels & Milestones — cara mencatat bug report, feature request, dan task, lalu menghubungkannya ke commit dan PR sehingga issue tertutup otomatis. Sampai jumpa di episode 12!