githubpull requestkolaborasireviewMahir4 mnt baca

Pull Request: Alur Kolaborasi Standar Industri

Alur lengkap branch, push, buka PR, code review, sampai merge di GitHub seperti tim profesional.

Apa itu Pull Request?

Pull Request (PR) adalah proposal: "aku sudah selesai mengerjakan ini di branch-ku, tolong review lalu gabungkan ke main". PR adalah jantung kolaborasi di GitHub. Hampir semua perusahaan dan proyek open source mewajibkan semua perubahan masuk lewat PR, tidak ada yang push langsung ke main.

Kenapa alur ini bagus? Karena setiap perubahan melewati review manusia sebelum jadi bagian resmi. Bug ketahuan lebih awal, gaya kode konsisten, dan pengetahuan tersebar ke seluruh tim.

Alur lengkap dari nol

1. Buat branch dan kerjakan.

bash
git switch -c fitur-notifikasi
# ... edit file ...
git add .
git commit -m "Tambah notifikasi email saat pendaftaran"

2. Push branch ke GitHub.

bash
git push -u origin fitur-notifikasi

3. Buka PR di website GitHub. Buka halaman repository, GitHub biasanya menampilkan banner kuning "Compare & pull request" untuk branch yang baru di-push. Klik, lalu isi:

  • Judul: jelas dan singkat, misal "Tambah notifikasi email saat pendaftaran".
  • Deskripsi: apa yang diubah, kenapa, dan cara mengetesnya. Ini template yang baik:
bash
# contoh isi deskripsi PR
## Apa yang diubah
- Kirim email sambutan via SMTP setelah user daftar
- Tambah template email di views/emails/

## Cara tes
1. Daftar akun baru
2. Cek inbox email testing

## Catatan
Butuh konfigurasi SMTP di .env (lihat .env.example)

4. Minta review. Tag teman tim sebagai reviewer. Mereka bisa memberi komentar di baris kode tertentu, meminta perubahan (request changes), atau menyetujui (approve).

5. Merge setelah disetujui. Penulis PR (atau maintainer) menekan tombol Merge. Ada tiga strategi merge di GitHub:

  • Create a merge commit: riwayat jujur apa adanya, cocok untuk fitur besar.
  • Squash and merge: semua commit PR digabung jadi satu commit rapi di main. Cocok kalau commit di branch berantakan ("fix", "fix lagi", "beneran fix").
  • Rebase and merge: riwayat lurus tanpa merge commit, cocok untuk PR kecil yang bersih.

6. Hapus branch. Setelah merge, GitHub menawarkan tombol "Delete branch". Hapus saja, riwayatnya sudah aman di main.

Etika PR yang baik

  • Satu PR = satu tujuan. Jangan campur fitur baru dengan refactor besar. PR kecil (di bawah ~300 baris perubahan) jauh lebih cepat di-review.
  • Jangan buka PR draft ke main yang masih berantakan, kecuali memang butuh diskusi awal (pakai fitur Draft PR).
  • Respons review dengan perbaikan, bukan debat kusir. Kalau tidak setuju, jelaskan alasan teknisnya dengan tenang.
  • Jangan merge PR sendiri kalau aturan tim mengharuskan review orang lain. Di banyak perusahaan ini dilarang keras.

Mengecek status PR dari terminal

bash
# install GitHub CLI sekali
# https://cli.github.com

# lihat daftar PR
gh pr list

# lihat detail PR saat ini
gh pr view

# checkout PR teman untuk dites lokal
gh pr checkout 42

GitHub CLI (gh) sangat membantu kalau kamu lebih nyaman di terminal daripada bolak-balik buka browser.

Catatan teknis: PR di GitHub bukan fitur Git murni, melainkan fitur platform. Artinya konsep "pull request" tidak ada di Git command line. Platform lain punya nama berbeda: GitLab menyebutnya Merge Request. Konsepnya sama persis: proposal penggabungan branch yang butuh review. Jadi skill PR-mu bisa dipakai di GitLab atau Bitbucket juga, hanya istilahnya yang beda.

Ringkasan

Alurnya: branch → kerjakan → push → buka PR dengan deskripsi jelas → review → merge → hapus branch. PR kecil dan fokus di-review lebih cepat. Kuasai alur ini dan kamu sudah siap kerja di tim profesional mana pun.