Git bisect: cari commit perusak tanpa baca 200 commit

Bug muncul. Kamu tahu kemarin masih jalan. Sekarang rusak. Di antaranya ada 200 commit — punya orang lain, punya kamu sendiri minggu lalu yang sudah kamu lupa isinya.

Cara amatir: baca satu-satu dari atas, atau git log -p sambil scroll dan berharap insight turun. Bisa 40 menit. Bisa juga nggak ketemu.

Cara yang benar: binary search. Git yang ngerjain, kamu cuma jawab "bagus" atau "rusak".

Kenapa 200 commit cuma butuh 8 langkah

Setiap jawabanmu memotong sisa rentang jadi separuh. 200 → 100 → 50 → 25 → 13 → 7 → 4 → 2 → 1. Sekitar log₂(n), jadi 8 commit checkout, bukan 200. Untuk repo 5.000 commit pun cuma ~13 langkah.

Yang penting: git yang milih commit mana yang dites. Kamu nggak perlu tahu commit mana yang "kayaknya" salah. Ini yang bikin bisect beda dari tebak-tebakan — zero knowledge required.

Alur dasar

git bisect start
git bisect bad                  # HEAD sekarang, yang rusak
git bisect good v1.4.0          # tag/commit terakhir yang kamu yakin sehat

# git sekarang checkout ke commit tengah. Tes manual:
npm test                        # atau: buka browser, klik tombolnya, whatever

git bisect good                 # kalau tes LULUS di commit ini
git bisect bad                  # kalau GAGAL
# ulangi sampai git bilang: "<sha> is the first bad commit"
git bisect reset                # WAJIB — balik ke HEAD semula

Realita lapangan: kamu akan melakukan good/bad sekitar 5–8 kali. Tiap kali seluruh working tree berubah di bawah kaki — ini aneh pertama kali, tapi itu memang cara kerjanya. Git relatif aman: dia simpan posisi awal, dan git bisect reset mengembalikan semuanya.

Naik level: `git bisect run` — biarkan skrip yang jawab

Kalau bug-mu bisa dideteksi otomatis (test gagal, exit code non-zero, output tertentu), kamu nggak perlu duduk nonton. Kasih git skrip, dia jalan sendiri sampai selesai:

git bisect start HEAD v1.4.0
git bisect run npm test -- --grep "checkout total"

Aturan kontrak skrip: exit 0 = good, exit 1–127 (selain 125) = bad, exit 125 = skip (commit nggak bisa dites — misal gagal build karena dependensi belum ada).

125 itu penyelamat. Tanpa itu, commit yang kebetulan nggak compile akan dicap "biang kerok" dan hasil bisect-mu meleset. Pakai:

#!/bin/sh
npm ci || exit 125        # nggak bisa build → skip, bukan bad
npm test || exit 1
exit 0

Contoh nyata yang saya jalankan barusan di repo 20 commit, dengan bug sengaja disisipkan di commit ke-13 (add() diubah jadi a - b):

$ git bisect start HEAD HEAD~19
$ git bisect run python3 t.py
0303332 is the first bad commit
    c13
bisect found first bad commit

Lima langkah untuk 20 commit, nol intervensi manual, hasil tepat di c13. Skrip tesnya cuma 3 baris.

Empat jebakan yang bikin hasil bisect bohong

State yang nggak ikut di-commit. node_modules basi, .env beda, database lokal sudah termigrasi. Bisect akan menyalahkan commit yang salah dengan sangat percaya diri. Solusi: bungkus tes dalam docker run bersih, atau minimal npm ci tiap iterasi (dan exit 125 kalau gagal).
Bug non-deterministik. Kalau tesnya flaky, bisect flaky juga. Jalankan tes 3x dalam skrip, gagal kalau 2 dari 3 gagal.
Merge commit. Default git akan menanyakan apakah mau masuk ke side branch. Kalau riwayatmu penuh merge, git bisect start --first-parent membatasi pencarian ke jalur main saja — jauh lebih cepat, dan biasanya cukup.
Lupa git bisect reset. Kamu tinggal di detached HEAD, commit berikutnya masuk ke tempat aneh. Kalau bingung: git bisect reset selalu aman.

Kapan JANGAN pakai bisect

Bug ada di commit yang belum pernah jalan benar (fitur baru rusak sejak lahir) — nggak ada "good" untuk dijadikan anchor.
Masalahnya di infrastruktur, bukan kode: DNS, kuota API, config server berubah tanpa commit. Bisect akan nemu commit acak yang kebetulan berdekatan waktunya.
Rentangnya cuma 3 commit. Baca git log -p saja, lebih cepat dari setup.

Satu hal yang bisa langsung dipakai

Hari ini, saat kamu menemukan bug regresi, jangan langsung baca diff. Jalankan ini dulu:

git bisect start HEAD <tag-yang-terakhir-sehat>

Lalu tes manual good/bad sampai selesai. Kebiasaan kecil: tandai rilis dengan git tag yang rapi — v1.4.0, bukan "rilis jumat". Tag adalah anchor bisect-mu nanti. Tanpa tag, kamu kehilangan titik "terakhir sehat" dan bisect jadi jauh lebih mahal.

Kalau bug-mu punya tes otomatis, langsung git bisect run <perintah tes>. Tutup laptop. Balik, sudah ada jawabannya.

Takeaway

Bisect mengubah "bug ini muncul entah kapan" jadi pertanyaan yang punya jawaban pasti — dalam log₂(n) langkah. Kamu nggak perlu pintar menebak; kamu hanya perlu bisa bilang "ini bagus" atau "ini rusak".