Pull Request, Merge Request & Code Review

Pull Request (GitHub) atau Merge Request (GitLab) adalah tempat perubahan diusulkan, diuji, dan didiskuisikan sebelum masuk ke branch utama. Review yang baik menangkap bug lebih awal dan menyebarkan pengetahuan tim.

Alur PR/MRCopy Anchor Link

branch ──push──▶ PR/MR ──CI──▶ review ──approval──▶ merge ──▶ deploy
                    │            │
                    └── gagal ───┴── perbaiki

1. Buat branch dari main.
2. Commit perubahan kecil.
3. Push dan buka PR/MR.
4. CI menjalankan lint, test, build, scan.
5. Reviewer memberi komentar dan approval.
6. Merge sesuai strategi yang disepakati.
7. Hapus branch.

Template PR/MRCopy Anchor Link

Simpan di .github/pull_request_template.md atau .gitlab/merge_request_templates/default.md.

## Ringkasan
Menambahkan endpoint health check.

## Perubahan
- Endpoint GET /health
- Test unit
- Dokumentasi

## Cara uji
1. Jalankan `npm test`
2. Jalankan `curl localhost:3000/health`

## Checklist
- [ ] Test lulus
- [ ] Dokumentasi diperbarui
- [ ] Tidak ada rahasia di diff
- [ ] Sudah diuji di staging

Status checksCopy Anchor Link

Wajibkan pemeriksaan otomatis sebelum merge:

Jika check gagal, perbaiki kode, jangan memaksa merge.

Review yang efektifCopy Anchor Link

Untuk authorCopy Anchor Link

• Jelaskan apa dan mengapa, bukan hanya daftar file.
• Jaga PR tetap kecil (< 400 baris bila mungkin).
• Pisahkan refactor dari perubahan perilaku.
• Sertakan screenshot/log bila relevan.
• Respon komentar dengan perubahan atau alasan.

Untuk reviewerCopy Anchor Link

• Fokus pada kebenaran, keamanan, keterbacaan, dan test.
• Bedakan blocking dan saran.
• Beri komentar spesifik pada baris terkait.
• Hindari gaya pribadi yang tidak tercantum di guideline.
• Setujui setelah concern utama selesai.

CODEOWNERSCopy Anchor Link

Reviewer otomatis berdasarkan area:

# GitHub .github/CODEOWNERS
*                 @org/engineering
/src/api/         @org/api-team
/infra/           @org/platform-team

Dengan branch protection, approval dari code owner dapat diwajibkan.

Strategi mergeCopy Anchor Link

Untuk banyak tim, squash merge memberi riwayat yang mudah dibaca dan rollback per fitur.

Menangani konflikCopy Anchor Link

git fetch origin
git rebase origin/main
# selesaikan konflik
git add <file>
git rebase --continue
git push --force-with-lease

Gunakan --force-with-lease, bukan --force, agar tidak menimpa pekerjaan orang lain.

Draft dan stacked PRCopy Anchor Link

• Draft PR — tandai belum siap review.
• Stacked PR — pecah fitur besar menjadi beberapa PR berurutan.
• Draft release — siapkan changelog sebelum rilis.

Review keamananCopy Anchor Link

Periksa khusus:

• Apakah ada secret, token, atau password di diff?
• Apakah input divalidasi?
• Apakah query database aman dari injection?
• Apakah dependency baru tepercaya?
• Apakah permission/file access sesuai?
• Apakah log membocorkan data sensitif?

Praktik: alur PR lengkapCopy Anchor Link

git switch -c fix/health-timeout
# perubahan
git add -p
git commit -m "fix(api): tangani timeout health check"
git push -u origin fix/health-timeout

Buka PR, isi template, tunggu CI. Setelah approval:

git switch main
git pull --ff-only
git merge --squash fix/health-timeout
git commit -m "fix(api): tangani timeout health check (#57)"
git push origin main
git branch -d fix/health-timeout

RingkasanCopy Anchor Link

• PR/MR adalah gerbang kualitas sebelum perubahan masuk main.
• Template, status checks, dan code owners membuat review konsisten.
• Review fokus pada kebenaran, keamanan, dan keterbacaan.
• Squash merge sering menjadi pilihan untuk riwayat yang bersih.