Belajar Git Branching Strategies - Pull Request & Code Review Workflow
Pull Request sebagai gerbang kualitas kode: deskripsi PR yang baik, code review best practice, branch protection rules untuk mengamankan branch utama, dan tiga merge strategy — merge commit, squash merge, dan rebase merge — beserta trade-off masing-masing.
#Pendahuluan
Setelah di episode 4 kita mempelajari Feature Branch Workflow — alur kerja lengkap dari branch creation hingga merge — pada episode ini kita mendalami Pull Request (PR) sebagai mekanisme inti dari kolaborasi Git modern. PR bukan hanya tombol "merge" — ia adalah forum diskusi kode, gerbang kualitas, dan dokumentasi perubahan.
PR yang baik mengurangi bug, meningkatkan kualitas kode, dan mempercepat onboarding developer baru. PR yang buruk menjadi bottleneck yang memperlambat seluruh tim.
#Pull Request sebagai Gerbang Kualitas
#Deskripsi PR yang Baik
Sebuah PR yang efektif harus menjawab tiga pertanyaan:
- Apa yang berubah? — Ringkasan perubahan utama.
- Mengapa perubahan ini diperlukan? — Konteks bisnis atau teknis.
- Bagaimana cara menguji? — Instruksi reproduksi atau test case.
## What
- Menambahkan endpoint `/api/search` untuk pencarian produk
- Menambahkan validasi input dengan Zod schema
## Why
User membutuhkan pencarian produk karena katalog sudah mencapai 10k+ item.
Feature ini adalah prerequisite untuk filter avanzed di episode berikutnya.
## How to test
1. `GET /api/search?q=laptop` harus mengembalikan array produk
2. `GET /api/search?q=` harus return 400 dengan pesan validasi
3. Jalankan `npm test` untuk memastikan semua test passing#Size Matters: PR Kecil Lebih Baik
Usahakan PR tetap kecil — idealnya kurang dari 400 baris perubahan. PR besar sulit di-review, meningkatkan risiko bug terlewat, dan memperlambat merge. Jika perubahan besar, pertimbangkan untuk memecahnya menjadi beberapa PR bertahap.
#Code Review Best Practice
#Untuk Reviewer
Fokus pada empat aspek utama:
- Desain — Apakah pendekatan ini tepat? Ada alternatif yang lebih baik?
- Kejelasan — Apakah kode mudah dipahami? Naming cukup jelas?
- Potensi bugs — Ada edge case yang terlewat? Race condition?
- Test coverage — Apakah perubahan punya test yang memadai?
Hindari mengomentari style yang bisa di-otomasi (gunakan linter/formatter). Fokus pada substansi.
#Untuk Author
- Deskripsi PR jelas dan lengkap.
- PR kecil (< 400 baris) agar mudah di-review.
- Commit messages bersih dan informatif.
- Tulis test sebelum meminta review.
#Branch Protection Rules
Branch protection rules memaksa workflow yang sehat di branch tertentu (biasanya main). Di GitHub:
- Wajib passing CI sebelum merge — lint, test, build harus green.
- Minimal 1-2 approval dari reviewer.
- Tidak boleh force-push ke branch yang diproteksi.
- Tidak boleh delete branch yang diproteksi.
Tip
Gunakan CODEOWNERS file untuk auto-assign reviewer berdasarkan path file. Contoh: src/api/** @team-backend akan otomatis assign tim backend untuk review perubahan di folder src/api/.
#Merge Strategy di PR
GitHub dan GitLab menawarkan tiga cara merge. Pemilihan strategy ini berdampak pada history di main:
#Merge Commit
Mempertahankan semua commits dalam PR + satu merge commit. History lengkap terlihat, tetapi bisa menjadi noise jika banyak commit kecil (typo fix, WIP).
#Squash and Merge
Menggabungkan semua commits dalam PR menjadi satu commit bersih di main. History main menjadi rapi, tetapi detail individual commits di branch asli hilang.
#Rebase and Merge
Menempatkan ulang commits PR di atas main tanpa merge commit. History linear dan bersih, tetapi commits asli di branch hilang (di-rewrite).
| Strategy | History main | Detail Commits | Best For |
|---|---|---|---|
| Merge Commit | Merge commit + semua commits | Lengkap | Audit trail, regulated industries |
| Squash Merge | Satu commit per PR | Dirangkum | Tim yang ingin history bersih |
| Rebase Merge | Linear tanpa merge commit | Individual commits | Tim yang peduli linear history |
#Penutup
Pada episode 5 ini, kalian telah memahami Pull Request & Code Review:
- PR adalah forum diskusi kode, bukan sekadar tombol merge.
- Deskripsi PR harus menjawab: apa, mengapa, bagaimana test.
- PR kecil (< 400 baris) lebih mudah di-review dan lebih cepat di-merge.
- Branch protection rules memaksa CI passing dan approval sebelum merge.
- Tiga merge strategy: merge commit (lengkap), squash (bersih), rebase (linear).
Di episode 6 selanjutnya kita akan mempelajari GitFlow Workflow — salah satu branching strategy paling terstruktur yang dikembangkan oleh Vincent Driessen, dengan lima jenis branch: main, develop, feature/*, release/*, dan hotfix/*. Sampai jumpa di episode 6!