Bisect Otomatis dengan git bisect run

Masalah klasik: "dulu jalan, sekarang rusak"

Bug muncul di kode yang minggu lalu baik-baik saja. Di antara 50 commit sejak itu, satu commit adalah pelakunya. Memeriksa satu per satu butuh 50 kali tes. git bisect memakai pencarian biner: tiap langkah ia melompat ke tengah rentang, sehingga 50 commit cukup sekitar 6 kali tes. Kenapa ini ada? Karena menemukan commit penyebab adalah separuh dari debugging, dan manusia buruk dalam pencarian biner manual.

Cara kerja manual dulu (biar paham konsepnya)

git bisect start
git bisect bad HEAD
git bisect good v1.2.0

Git menghitung titik tengah dan checkout ke sana, lalu bertanya: commit ini good atau bad? Kamu jawab:

git bisect good   # kalau commit ini masih benar
git bisect bad    # kalau bug sudah muncul di sini

Ulangi sampai Git mengumumkan: "a1b2c33 adalah commit bad pertama". Lalu keluar dengan git bisect reset untuk kembali ke branch semula. Mode manual ini mengajarkan konsepnya, tapi melelahkan kalau tiap langkah butuh menjalankan tes 2 menit.

Otomatisasi dengan git bisect run

Kalau kamu punya skrip yang bisa menjawab good/bad sendiri, serahkan semuanya ke Git:

git bisect start
git bisect bad HEAD
git bisect good v1.2.0
git bisect run ./cek-bug.sh

Git akan checkout tiap titik tengah, menjalankan skrip, dan membaca exit code-nya. Contoh skrip cek-bug.sh:

#!/bin/bash
npm test -- --grep "fitur pembayaran"

Aturan exit code yang dipakai Git: 0 berarti good, 1 sampai 124 berarti bad (kecuali 125), dan 125 berarti skip (commit ini tidak bisa dites, misalnya gagal build, jadi Git melewatinya dan lanjut). Kenapa aturan ini ada? Karena inilah konvensi Unix: 0 sukses, non-zero gagal, dan 125 adalah kode khusus yang disepakati Git sebagai "tidak bisa dinilai".

Contoh sesi otomatis:

git bisect run ./cek-bug.sh
# ...
# a1b2c33 is the first bad commit
git bisect reset

Kamu tinggal menunggu. Untuk 50 commit, kira-kira 6 putaran tes berjalan sendiri.

Kapan manual, kapan otomatis

Pakai git bisect run ketika: bug bisa direproduksi oleh skrip (test suite, curl ke endpoint, skrip yang mengecek output program). Ini kasus ideal dan paling sering.

Tetap pakai manual ketika: bug hanya terlihat oleh mata manusia (tampilan UI rusak, animasi patah), atau butuh interaksi yang tidak bisa diskrip. Juga saat skrip tesnya sendiri belum bisa dipercaya: kalau tesnya flaky (kadang lolos kadang gagal tanpa alasan), hasil bisect otomatis ikut ngaco.

Tips penting: pastikan skrip tes cepat. Kalau satu putaran tes butuh 10 menit dan ada 8 putaran, kamu menunggu 80 menit. Jalankan subset tes yang relevan saja, bukan seluruh suite.

Kesalahan umum pemula

Salah: lupa git bisect reset setelah selesai, lalu bingung kenapa HEAD nyangkut di commit tengah-tengah dan branch "hilang". Benar: selalu akhiri dengan git bisect reset. Git mengembalikanmu ke posisi semula. Jadikan ini kebiasaan seperti menutup pintu setelah masuk.

Salah: memakai skrip tes yang flaky untuk git bisect run, lalu Git menunjuk commit yang salah sebagai pelaku. Benar: pastikan skrip deterministik dulu: jalankan 3 kali di commit yang diketahui bad, harus gagal 3 kali. Baru percayakan ke bisect.