Bug tiba-tiba muncul, tapi kamu tidak tahu commit mana penyebabnya. git bisect menemukannya dengan binary search — O(log n) bukan O(n).

Intuisi: kalau ada 1024 commit sejak terakhir "good", bisect hanya perlu ~10 langkah untuk menemukan commit jahat.

Flow dasar:

$ git bisect start
$ git bisect bad                  # HEAD saat ini bug
$ git bisect good v1.0            # v1.0 masih oke

Bisecting: 500 revisions left to test
[abc123] checkout ke commit tengah

Test aplikasi. Lalu beritahu Git:

$ git bisect good                 # commit ini tidak bug
# atau
$ git bisect bad                  # commit ini bug

Ulangi sampai Git mengumumkan:

abc1234 is the first bad commit
commit abc1234
Author: ...
    tambah fitur X

Terakhir, keluar dari mode bisect:

$ git bisect reset                # kembali ke HEAD semula

Otomatis dengan script:

Jika kamu punya test/skrip yang return 0 untuk "good" dan non-zero untuk "bad":

$ git bisect start HEAD v1.0
$ git bisect run ./test.sh

Git akan otomatis checkout, jalankan script, mark good/bad, lanjut — sampai ketemu. Contoh skrip:

#!/bin/sh
npm install --silent
npm test 2>&1 | grep -q "fails"
# jika grep menemukan "fails" → exit 0 (dianggap good? salah!)
# gunakan exit code yang jelas:
if npm test; then exit 0; else exit 1; fi

Bisect skip:

Commit tengah tidak bisa di-build (misal dependency rusak)? Lewati:

$ git bisect skip

Git akan mencoba commit terdekat lainnya.

Bisect di merge commits:

Bisect jalan di DAG, jadi aman di history dengan merge. Kalau penyebab berada di dalam feature branch, Git akan menelusuri commit branch tersebut.

Tips praktis:

• Simpan skrip reproduksi bug sebelum bisect — commit tengah belum punya skrip itu
• Pakai --first-parent kalau hanya ingin bisect di merge line utama
• Kalau test lambat, git bisect run tetap lebih cepat dari manual karena tidak ada jeda manusia

Kapan tidak perlu bisect? Kalau kamu sudah tahu commit jahatnya dari git log -S "kode yang rusak" (pickaxe) — itu lebih cepat.