Bug muncul, tapi dulu tidak ada. Di antara commit mana pecahnya? git bisect pakai binary search di history commit — cek commit di tengah, tanyakan "baik atau rusak?", lanjut ke setengah yang tepat. 1024 commit jadi tinggal 10 langkah.
Alur dasar:
# 1. Mulai bisect
git bisect start
# 2. Tandai commit saat ini (yang bermasalah)
git bisect bad
# 3. Tandai commit lama yang kita tahu masih baik
git bisect good v2.1.0
# → Git akan checkout commit di tengah
# → Test fitur yang bermasalah
# 4. Jika commit ini rusak juga:
git bisect bad
# 5. Jika commit ini masih baik:
git bisect good
# ... ulangi sampai git menemukan first bad commit
Setelah selesai:
a1b2c3d is the first bad commit
commit a1b2c3d
Author: Siapa <[email protected]>
Date: Wed Mar 1 14:00:00 2026 +0700
refactor user validation
Langkah akhir:
git bisect reset # kembali ke HEAD asli
Otomatisasi dengan script:
Jika ada test yang deterministik, git bisect run bisa otomatis:
git bisect start
git bisect bad
git bisect good v2.1.0
git bisect run npm test -- --filter="the broken feature"
# exit code 0 → good, 1-127 (kecuali 125) → bad, 125 → skip
Git akan checkout setiap commit, jalankan npm test, dan tentukan sendiri baik/buruk.
Contoh script kustom:
#!/bin/bash
# test.sh — return 0 jika commit baik, 1 jika buruk
npm run build
node -e "require('./dist/feature').work()" > /dev/null
exit $?
git bisect run ./test.sh
Edge cases:
1. Commit yang tidak bisa di-test (broken build):
git bisect skip # lewati commit ini
2. Bug bergantung pada env eksternal: Pastikan env konsisten (DB state, env vars). Pakai Docker jika perlu.
3. Bug di test baru:
git bisect kadang menunjuk commit yang menambah test, bukan commit yang memperkenalkan bug. Cek manual.
4. First bad commit adalah merge commit:
Bug bisa dari salah satu parent. Jalankan git bisect di branch individual.
Workflow best practice:
- Minimal repro dulu — punya cara reproduce cepat (<30 detik), automated
- Scope sempit — mulai bisect dengan range kecil kalau bisa
- Dokumentasikan — catat commit hash yang salah + root cause untuk tim
- Fix + regression test — tambahkan test yang akan gagal tanpa fix
Contoh kalkulasi efisiensi:
- 500 commit antara "good" dan "bad"
- Tanpa bisect: O(500), harus cek satu per satu
- Dengan bisect: log₂(500) ≈ 9 test saja
Kombinasi dengan git log --oneline:
# Lihat range yang akan di-bisect
git log --oneline v2.1.0..HEAD | wc -l
# Bisect hanya di folder tertentu (lebih cepat kalau yakin lokal ke folder)
git bisect start -- src/auth/
Saat tidak pakai bisect:
- Bug baru dari kemarin (cukup cek beberapa commit terakhir)
- Commit history di-squash (hanya 1-2 commit per PR → pakai git log biasa)
- Regression terlihat jelas di CI (lihat pipeline yang pertama gagal)
