GitHub Pull Request dan Code Review: Panduan untuk Tim

Pull Request (PR) adalah jantung dari kolaborasi di GitHub. PR bukan hanya cara untuk merge kode — ini adalah forum diskusi, proses review, dan dokumentasi mengapa perubahan dibuat. Code Review yang baik meningkatkan kualitas kode, menyebarkan pengetahuan di tim, dan mencegah bug masuk ke production.

Anatomi Pull Request

Membuat PR yang Efektif

Judul PR Gunakan format Conventional Commits:

feat(auth): tambah login dengan Google OAuth
fix(api): perbaiki error 500 pada endpoint /users
docs: update README dengan instruksi Docker

Deskripsi PR Jawab pertanyaan: Apa yang berubah? Mengapa? Bagaimana cara testnya?

## 🎯 Tujuan
Tambah opsi login menggunakan Google OAuth sebagai alternatif
login email/password biasa.

## 📋 Perubahan
- Tambah endpoint `POST /auth/google`
- Integrasi dengan Google OAuth 2.0 SDK
- Update middleware autentikasi untuk handle token Google
- Tambahkan variabel env `GOOGLE_CLIENT_ID` dan `GOOGLE_CLIENT_SECRET`

## 🧪 Cara Test
1. Copy `.env.example` ke `.env`
2. Isi `GOOGLE_CLIENT_ID` dan `GOOGLE_CLIENT_SECRET`
3. Jalankan `docker compose up`
4. Buka `http://localhost:3000/login`
5. Klik "Login dengan Google"

## 📸 Screenshot
[Screenshot tampilan button Login Google]

## ⚠️ Breaking Changes
Tidak ada.

Closes #45

Status PR

Draft PR — PR yang belum siap di-review. Bisa dibuat dari awal sebagai draft untuk menandai “sedang dikerjakan” dan mendapat early feedback
Open PR — siap di-review
Merged PR — sudah di-merge
Closed PR — ditutup tanpa merge

# Push sebagai draft PR (harus dibuat dari GitHub UI atau CLI)
gh pr create --draft --title "wip: fitur login Google" --body "Masih dalam pengerjaan"

Melakukan Code Review

Cara Membuka Review di GitHub

Buka PR yang akan di-review
Klik tab Files changed
Klik ikon + di samping baris kode untuk memberikan komentar inline
Klik Review changes → pilih tipe review → submit

Tiga Tipe Review

Comment — komentar umum tanpa approval/rejection
Approve — kode sudah oke, siap di-merge
Request changes — ada yang perlu diperbaiki sebelum bisa di-merge

Cara Memberikan Review yang Konstruktif

Berikan konteks, bukan hanya perintah:

❌ "Ganti ini."
✅ "Pertimbangkan menggunakan Map di sini daripada array, karena lookup O(1) vs O(n) — akan signifikan jika data besar."

Bedakan blocking vs saran:

// Blocking — harus diperbaiki
🚫 Security issue: password tidak di-hash sebelum disimpan ke database.

// Saran — opsional, terima atau tolak
💡 Nit: bisa pakai optional chaining di sini: `user?.profile?.avatar`

// Pujian — beri juga feedback positif
✨ Suka cara error handling di sini, sangat informatif untuk debugging.

Prefix yang umum dipakai di komentar review:

nit: — nitpick kecil, tidak blocking
blocking: atau 🚫 — harus diperbaiki
suggestion: atau 💡 — saran opsional
question: atau ❓ — pertanyaan klarifikasi
praise: atau ✨ — apresiasi

Merespons Review

Sebagai Author PR

# Update kode berdasarkan review
nano src/auth.js

git add src/auth.js
git commit -m "refactor: hash password sebelum simpan ke db"
git push

Untuk setiap komentar review, balas dengan apa yang dilakukan:

“Done ✅” — sudah diperbaiki
“Good point, sudah diubah ke…” — dengan penjelasan
“Tidak setuju karena… Gimana menurutmu?” — untuk diskusi

Re-request Review

Setelah semua komentar ditangani, klik Re-request review di samping nama reviewer agar mereka tahu PR sudah diupdate.

Branch Protection Rules untuk Memaksa Code Review

Di Settings → Branches → Branch protection rules:

✅ Require a pull request before merging
  ✅ Require approvals: 1 (atau lebih)
  ✅ Dismiss stale pull request approvals when new commits are pushed
  ✅ Require review from Code Owners

✅ Require status checks to pass before merging
  ✅ Require branches to be up to date before merging
  Status checks: CI / test, CI / lint

✅ Require conversation resolution before merging
✅ Do not allow bypassing the above settings

CODEOWNERS — Review Otomatis ke Orang yang Tepat

File .github/CODEOWNERS mendefinisikan siapa yang otomatis di-request sebagai reviewer berdasarkan file yang berubah:

# Semua file — default owner
*                   @username-lead

# Folder tertentu
/src/auth/          @username-security-team
/docs/              @username-docs-team
*.sql               @username-dba

# File spesifik
package.json        @username-frontend-lead
docker-compose.yml  @username-devops

GitHub CLI untuk PR

# Install GitHub CLI
# https://cli.github.com

# Buat PR
gh pr create --title "feat: tambah login Google" --body "..." --base main

# Lihat daftar PR
gh pr list

# Review PR
gh pr review 42 --approve
gh pr review 42 --request-changes --body "Password harus di-hash dulu"

# Merge PR
gh pr merge 42 --squash --delete-branch

# Checkout PR untuk test lokal
gh pr checkout 42

Merge Strategy

GitHub menyediakan tiga opsi merge:

Strategi	Deskripsi	Kapan Dipakai
Merge commit	Buat merge commit, pertahankan semua commit	Histori detail
Squash and merge	Gabungkan semua commit jadi satu	Commit bersih di main
Rebase and merge	Rebase commit ke main, no merge commit	Histori linear

Banyak tim menggunakan Squash and merge untuk main branch agar histori tetap bersih — satu PR = satu commit di main.

Kesimpulan

PR dan Code Review yang baik adalah investasi jangka panjang untuk kualitas kode dan kesehatan tim. Review bukan tentang mencari kesalahan — ini tentang berbagi pengetahuan, meningkatkan kualitas, dan membangun kepercayaan dalam tim.

Di artikel berikutnya, kita bahas .gitignore — cara memberitahu Git file mana yang tidak perlu dilacak.