Git Bisect: Temukan Commit Penyebab Bug

Bug yang baru muncul setelah beberapa commit sering memancing kebiasaan menebak: apakah masalahnya di dependency, konfigurasi, atau perubahan kode semalam? Git Bisect memberi cara lebih disiplin. Dengan pencarian biner, Git membantu menyempitkan commit yang memperkenalkan regresi berdasarkan tes yang bisa membedakan kondisi good dan bad.

Tutorial ini membangun repository tiruan terpisah, memasukkan satu bug secara sengaja, lalu menemukan commit penyebabnya. Tidak ada repository kerja pembaca yang diubah.

Meja developer dan laptop untuk ilustrasi pencarian regresi Git — Foto ilustrasi oleh Christopher Gower / Unsplash; bukan dokumentasi pengujian.

Konsep Git Bisect: dari ratusan commit ke beberapa tes

Pada awalnya kita perlu dua titik yang meyakinkan: versi yang pernah berfungsi (good) dan versi yang diketahui bermasalah (bad). Git memilih commit di tengah riwayat, kemudian menjalankan tes atau meminta keputusan kita. Pengulangan ini terus memperkecil ruang pencarian. Metode ini paling efektif ketika kondisi yang dites stabil dan perubahannya dapat dipetakan pada urutan commit.

ILUSTRASI KONSEPTUAL / ALUR PROSES

Commit good dan bad diketahuiGit memilih commit tengah, jalankan tesTemukan first bad commit

Diagram penjelas, bukan screenshot pengujian nyata.

Persyaratan dan keamanan

Git tersedia di terminal Linux/macOS atau Git Bash; contoh menggunakan shell POSIX yang umum pada Linux.
Tidak memerlukan server remote atau akun GitHub. Semua langkah berlangsung dalam folder sementara milik pengguna.
Git Bisect mengubah checkout selama investigasi dan bisa membuat working tree berada pada posisi detached HEAD. Pada proyek nyata, commit atau stash perubahan terlebih dahulu; hindari bisect di direktori berisi pekerjaan belum disimpan.
Untuk percobaan, gunakan konfigurasi identitas lokal repository; email example.invalid adalah domain dummy, bukan identitas pribadi.

git --version
command -v git
# Ubuntu/Debian jika Git belum terpasang:
# sudo apt update && sudo apt install git

Langkah 1 — Buat repository percobaan

LAB="$(mktemp -d)"
cd "$LAB"
git init
git config user.name 'Edelweis Lab'
git config user.email 'lab@example.invalid'
printf 'mode=aman\n' > app.conf
git add app.conf
git commit -m '01 stable'

Commit awal menjadi kondisi yang diharapkan bekerja. Semua perubahan berikut sengaja dibuat sederhana agar mudah ditelusuri.

Langkah 2 — Buat empat commit, satu berisi regresi

printf 'note=satu\n' >> app.conf
git add app.conf
git commit -m '02 documentation'
printf 'mode=rusak\n' > app.conf
git add app.conf
git commit -m '03 regression'
printf 'note=dua\n' >> app.conf
git add app.conf
git commit -m '04 unrelated'
git log --oneline --reverse

Isi app.conf pada versi terbaru sudah memiliki mode=rusak. Pada commit ketiga, kita sengaja mengganti nilai yang sebelumnya mode=aman. Commit keempat hanya menambah catatan, jadi ia bukan sumber awal masalah.

Langkah 3 — Tentukan tes otomatis

grep -q 'mode=aman' app.conf
printf 'Exit code: %s\n' "$?"

grep -q tidak mencetak baris, tetapi mengembalikan status 0 saat pola ditemukan dan 1 saat tidak ditemukan. Dalam lab ini, kondisi mode=aman berarti good. Pada Git Bisect otomatis, tes berstatus 0 = good, status 1–127 (kecuali 125) = bad; 125 menandakan revisi tidak bisa dites dan harus dilewati. Tes yang tidak deterministik, bergantung internet, atau memodifikasi data produksi akan menghasilkan keputusan yang sulit dipercaya.

Langkah 4 — Jalankan Git Bisect otomatis

git bisect start HEAD HEAD~3
git bisect run sh -c "grep -q 'mode=aman' app.conf"
git bisect log
git bisect reset

Perintah start HEAD HEAD~3 mendefinisikan commit paling baru sebagai bad dan tiga commit sebelumnya sebagai good. run lalu mengetes commit kandidat satu per satu. Hasil yang diharapkan mencantumkan 03 regression sebagai first bad commit. reset sangat penting untuk keluar dari sesi bisect dan mengembalikan checkout awal.

Hasil pengujian nyata, dengan batasan jelas

Lab 9 November 2026: pada Debian GNU/Linux 13 dengan Git 2.47.3, percobaan empat commit di atas berhasil menemukan commit bernama 03 regression sebagai first bad commit. ID hash bersifat unik setiap kali contoh dibuat, jadi jangan membandingkan hash persis dengan output lab lain. Ini bukan pengujian pada codebase produksi atau semua platform Git.

Bagaimana kalau ingin memberi label good/bad secara manual?

GOOD=$(git rev-parse HEAD~3)
BAD=$(git rev-parse HEAD)
git bisect start
# Tandai referensi yang disimpan sebelum checkout berpindah:
git bisect bad "$BAD"
git bisect good "$GOOD"
# Git akan memilih kandidat. Jalankan tes pada kandidat itu,
# lalu masukkan salah satu: git bisect good / git bisect bad
# Selesaikan dengan:
git bisect reset

Perhatian: contoh manual di atas harus dilakukan dari state repository normal, bukan saat sesi otomatis masih aktif. Jangan mengandalkan HEAD~3 setelah checkout berpindah ke kandidat; simpan commit good sejak awal jika menggunakan pendekatan manual pada riwayat yang kompleks.

Masalah umum dan solusinya

Git mengatakan working tree kotor: cek git status; simpan perubahan di branch/commit atau stash yang benar-benar dapat dipulihkan.
Tes gagal karena dependency lama: pakai git bisect skip untuk commit yang tak dapat dibangun, atau sediakan environment yang kompatibel. Jangan menandai kegagalan build yang tidak terkait sebagai bad.
Tes kadang berhasil kadang gagal: perbaiki tes agar deterministik; ulangi beberapa kali dan audit dependensi, clock, cache, serta akses jaringan.
Hasil first bad commit tidak cocok: periksa apakah commit good benar-benar baik, apakah bug muncul-hilang pada cabang berbeda, dan apakah tes mendeteksi gejala yang tepat.
Terjebak pada detached HEAD: gunakan git bisect reset, kemudian cek git status dan branch.

Verifikasi, pembersihan, dan penerapan pada proyek nyata

git status --short --branch
git log -4 --oneline
printf 'Folder lab: %s\n' "$LAB"
# Setelah yakin sudah tidak diperlukan:
# cd ~ && rm -r -- "$LAB"

Untuk proyek sungguhan, simpan tes minimal yang dapat membedakan kegagalan dan keberhasilan. Jika ada hasil yang meragukan, tulis ulang langkah reproduksi sebelum menyalahkan sebuah commit. Git Bisect menemukan perubahan awal yang berkorelasi dengan kegagalan tes, tetapi penyebab sistemik bisa melibatkan konfigurasi eksternal atau interaksi antarcommit.

Kesimpulan

Git Bisect mengubah debugging dari aktivitas menebak menjadi percobaan terarah. Kunci keberhasilannya bukan jumlah commit, melainkan kualitas definisi good/bad dan tes yang reproduktif. Mulai dari repository lab, pahami hasil setiap tahap, lalu adaptasikan prosesnya ke pipeline dan codebase sendiri.

Referensi resmi dan bacaan lanjutan

Status editorial: Lab Tested — alur otomatis diuji dengan Git 2.47.3 pada Debian 13; contoh manual dan integrasi CI lintas platform belum diuji dalam sesi ini.

Catatan editorial: Diagram bersifat konseptual kecuali diberi label sebagai hasil uji. Verifikasi konfigurasi di perangkat lu sendiri sebelum dipakai pada sistem produksi.

END OF NOTE.Jelajahi artikel lain ↗