Menyetujui / Approve: apa itu, approval dan code review di Git

Apa itu persetujuan pull request

Persetujuan (approval) — adalah review positif pada pull request, yang berarti reviewer telah memeriksa kode, tidak menemukan masalah kritis, dan menganggap perubahan siap untuk digabungkan. Di antarmuka GitHub, ini adalah tombol hijau «Approve» di halaman PR. Setelah persetujuan, penulis (atau peserta mana pun dengan hak tulis) dapat melakukan merge.

Proses persetujuan adalah bagian dari Branch Protection Rules. Pemilik repositori mengonfigurasi persyaratan wajib: jumlah minimum persetujuan (misalnya 1 atau 2), siapa yang dapat menyetujui (pemilik kode, anggota tim), dan apakah PR harus disetujui ulang setelah perubahan (Dismiss stale reviews). Tanpa mengonfigurasi aturan, persetujuan adalah langkah opsional, tetapi dalam tim profesional itu wajib.

GitLab menggunakan mekanisme serupa yang disebut Approval Rules. Di GitLab, Anda dapat mengonfigurasi berapa banyak persetujuan yang diperlukan dari berbagai grup (misalnya, 2 dari pengembang backend dan 1 dari DevOps). Setelah menerima semua persetujuan wajib, PR secara otomatis dibuka bloknya untuk merge dengan syarat pipeline CI/CD hijau.

Jenis review: Approve, Request Changes, Comment

Di GitHub dan GitLab terdapat tiga jenis review yang dapat ditinggalkan reviewer pada pull request. Setiap jenis memiliki status dan konsekuensi yang berbeda untuk proses penggabungan. Approve — hijau, Request Changes — merah, Comment — abu-abu netral. Pemilihan jenis tergantung pada kualitas kode dan kesiapan perubahan untuk diterima.

Approve — reviewer mengonfirmasi: kode ditulis dengan benar, sesuai standar, tidak mengandung kesalahan yang jelas, dan dapat digabungkan. Approve tidak berarti kode itu ideal — hanya cukup baik untuk produksi. Jika ada catatan kecil (gaya, penamaan), dapat ditinggalkan sebagai komentar tanpa memblokir PR.

Request Changes — reviewer menemukan masalah yang harus diperbaiki sebelum merge: kesalahan logika, kerentanan, pelanggaran arsitektur, tidak adanya tes. Setelah Request Changes, PR diblokir, dan untuk membuka blok diperlukan persetujuan ulang dari reviewer yang sama (jika opsi Dismiss stale reviews diaktifkan untuk commit baru).

• Approve — kode siap digabungkan, merge dapat dilakukan setelah CI lulus.
• Request Changes — perbaikan wajib, PR diblokir hingga review ulang.
• Comment — catatan umum atau saran tanpa memblokir PR.

Mengonfigurasi aturan persetujuan di repositori

Branch Protection Rules — adalah mekanisme GitHub untuk kontrol kualitas penggabungan. Dikonfigurasi di Settings → Branches untuk setiap cabang yang dilindungi (main, develop, release/*). Parameter utama: jumlah persetujuan wajib, pemilik kode (CODEOWNERS), pemeriksaan CI/CD wajib, dan larangan push tanpa PR.

Parameter Dismiss stale pull request approvals — secara otomatis menghapus persetujuan jika commit baru ditambahkan ke PR. Ini memastikan bahwa reviewer menyetujui versi kode yang tepat yang akan digabungkan. Tanpa pengaturan ini, penulis dapat menambahkan kode baru setelah persetujuan dan akan masuk ke main tanpa pemeriksaan ulang.

CODEOWNERS — file di root repositori yang menunjuk penanggung jawab untuk direktori yang berbeda. Jika PR menyentuh file milik pemilik kode, persetujuannya menjadi wajib. CODEOWNERS membagi zona tanggung jawab: pengembang iOS bertanggung jawab atas file Swift, DevOps — atas konfigurasi Docker, penguji — atas skenario pengujian.

# Contoh file CODEOWNERS di root repo

# Pengembang iOS memiliki kode Swift
*.swift @team/ios-developers

# DevOps memiliki konfigurasi CI/CD
.github/workflows/* @devops-team

# Insinyur QA meninjau tes
**/tests/* @qa-engineers

# Pemilik default untuk yang lainnya
* @tech-leads

Code review sebelum persetujuan: apa yang harus diperiksa

Code review sebelum persetujuan — adalah pemeriksaan sistematis kode, bukan pandangan sepintas pada diff. Code review berkualitas mencakup pemeriksaan arsitektur, logika, gaya, tes, dan keamanan. Tanpa pemeriksaan ini, persetujuan menjadi formalitas, bukan alat kontrol kualitas.

Apa yang diperiksa pertama: logika perubahan — apakah kode menyelesaikan tugas yang diberikan, apakah ada efek samping, apakah penanganan kasus batas benar. Tes — apakah tes baru mencakup semua skenario, apakah tes yang ada lulus setelah perubahan. Keamanan — apakah ada injeksi SQL, XSS, kebocoran data sensitif.

Apa yang tidak boleh menjadi subjek review: gaya pemformatan (untuk itu ada linter dan formatter), keputusan arsitektur yang diambil sebelumnya (dibahas sebelum penulisan kode). Jika review memiliki lebih dari 400 baris atau berlangsung lebih dari satu jam — ini adalah sinyal bahwa tugas terlalu besar dan memerlukan dekomposisi. Praktik terbaik review — porsi 200–400 baris dalam waktu 24 jam setelah pembuatan PR.

• Logika — kebenaran solusi tugas, penanganan kesalahan, kasus batas.
• Tes — cakupan skenario baru, kelulusan yang ada, tidak adanya tes flaky.
• Keamanan — tidak adanya injeksi, escape output, akses ke data.
• Kinerja — efisiensi algoritma, kueri berlebihan, kebocoran memori.
• Dokumentasi — apakah dokumentasi diperbarui, apakah komentar di bagian kompleks dapat dipahami.

Alur kerja dengan persetujuan dalam tim

Alur kerja tipikal dengan persetujuan dalam tim 5–10 pengembang terlihat seperti ini: pengembang membuat PR, menunjuk reviewer (biasanya 1–2 orang dari tim atau pemilik kode), CI/CD menjalankan pemeriksaan otomatis. Setelah menerima semua persetujuan wajib dan CI hijau, penulis melakukan merge. Waktu dari pembuatan PR hingga merge rata-rata 2 jam hingga 2 hari tergantung kompleksitas.

GitHub Actions memungkinkan otomatisasi merge setelah persetujuan. Jika aturan cabang dikonfigurasi, GitHub sendiri memblokir merge hingga semua kondisi terpenuhi. Beberapa tim menggunakan bors-ng atau Mergify — bot yang secara otomatis menggabungkan PR setelah menerima semua persetujuan dan CI lulus. Ini mempercepat proses dan menghilangkan faktor manusia saat merge.

Pendekatan modern — trunk-based development dengan cabang berumur pendek. Dalam alur kerja ini, persetujuan harus diperoleh dalam beberapa jam, jika tidak tugas dianggap usang dan memerlukan sinkronisasi ulang dengan main. Tim dengan budaya review tinggi bertujuan untuk waktu persetujuan tidak lebih dari 4 jam kerja.

Kesalahan dalam persetujuan dan cara menghindarinya

Kesalahan paling umum — persetujuan formal tanpa pemeriksaan kode nyata. Ketika PR besar atau tenggat waktu dekat, reviewer dapat menekan Approve tanpa mendalami perubahan. Ini meniadakan seluruh proses code review. Solusi: tetapkan batas ukuran PR (tidak lebih dari 400 baris) dan gunakan alat analisis kode (SonarQube, CodeClimate) untuk pemeriksaan otomatis.

Kesalahan kedua — persetujuan yang terlalu ketat. Mengharapkan kode ideal memblokir pengembangan. Reviewer terkadang meminta perbaikan catatan stilistika yang tidak mempengaruhi kualitas. Solusi: pisahkan dengan jelas catatan wajib (memblokir) dan saran opsional (komentar). GitHub memungkinkan untuk secara eksplisit menunjukkan apakah komentar bersifat memblokir.

Kesalahan ketiga — persetujuan tanpa pemeriksaan CI/CD. Bahkan jika kode terlihat benar, mungkin tidak dapat dikompilasi atau gagal dalam tes. Branch Protection yang dikonfigurasi secara otomatis memblokir merge saat CI merah, tetapi beberapa tim menonaktifkan perlindungan ini untuk kecepatan. Solusi: selalu periksa status CI sebelum persetujuan dan jangan pernah menyetujui PR dengan pipeline merah.

• Persetujuan formal — tidak adanya pemeriksaan kode nyata. Solusi: batas 400 baris per PR.
• Keketatan berlebihan — pemblokiran karena catatan stilistika. Solusi: pembagian menjadi blocking dan optional.
• Mengabaikan CI — persetujuan dengan pipeline merah. Solusi: selalu periksa status pemeriksaan.
• Penunjukan penulis — persetujuan dari penulis PR. Solusi: konfigurasi Branch Protection terhadap penulis.