Aplikasi yang kemarin berjalan normal tiba-tiba rusak, dan riwayat Git berisi ratusan commit baru. Memeriksa kode satu per satu jelas membuang waktu. Di sinilah git bisect berperan. Perintah bawaan Git ini menemukan commit penyebab bug dengan cara membagi dua rentang riwayat berulang kali, sehingga Anda cukup menguji belasan versi, bukan ratusan.
Banyak developer sudah memakai Git bertahun-tahun, tetapi belum pernah menjalankan git bisect. Akibatnya, mereka masih membaca diff commit demi commit atau menebak pelakunya lewat intuisi. Artikel ini membahas cara kerja git bisect, langkah manualnya, otomatisasi dengan script, penanganan situasi sulit, serta kesalahan yang sering membuat hasilnya menyesatkan.
Daftar Isi
- Apa itu git bisect
- Cara kerja git bisect
- Persiapan sebelum memulai
- Langkah manual mencari commit penyebab bug
- Contoh kasus nyata
- Otomatisasi dengan git bisect run
- Menangani commit yang tidak bisa diuji
- Istilah kustom untuk bug non-regresi
- Perintah pendukung yang berguna
- Git bisect pada riwayat dengan merge
- Git bisect dibanding blame dan log
- Penerapan dalam tim dan CI
- Kesalahan umum
- Pertanyaan yang sering diajukan
- Kesimpulan
Apa Itu Git Bisect dan Kapan Dipakai?
Git bisect adalah perintah di Git yang membantu Anda menemukan commit penyebab bug secara otomatis dan terarah. Anda cukup memberi tahu Git satu commit yang masih sehat dan satu commit yang sudah rusak. Setelah itu, Git memilihkan commit di tengah-tengahnya untuk Anda uji, lalu mempersempit rentang sampai satu commit tersisa.
Perintah ini paling berguna untuk menangani regresi, yaitu fitur yang dulu berfungsi lalu rusak setelah perubahan tertentu. Beberapa situasi yang cocok untuk git bisect antara lain:
- Bug muncul setelah merge besar, tetapi tidak jelas perubahan mana yang bertanggung jawab.
- Tes otomatis gagal di cabang utama, padahal minggu lalu masih lulus.
- Performa aplikasi menurun, dan Anda ingin tahu kapan penurunannya dimulai.
- Pelanggan melaporkan masalah pada versi rilis terbaru, sedangkan versi sebelumnya aman.
Sebaliknya, git bisect kurang berguna jika bug ada sejak commit pertama atau jika Anda tidak punya cara andal untuk mengetes apakah sebuah versi rusak. Inti dari perintah ini adalah kemampuan membedakan versi baik dan buruk secara konsisten.
Cara Kerja Git Bisect: Binary Search pada Riwayat Commit
Git bisect memakai prinsip pencarian biner. Alih-alih memeriksa commit berurutan, Git membelah rentang menjadi dua bagian setiap langkah. Jika commit di tengah ternyata rusak, pelakunya pasti berada di separuh yang lebih lama. Jika commit di tengah masih sehat, pelakunya ada di separuh yang lebih baru.
Keunggulannya terletak pada pertumbuhan yang logaritmik. Menggandakan jumlah commit hanya menambah satu langkah pengujian. Tabel berikut memperlihatkan perkiraan jumlah pengujian maksimal untuk menemukan commit penyebab bug.
| Jumlah commit dalam rentang | Pemeriksaan satu per satu (terburuk) | Git bisect (maksimal) |
|---|---|---|
| 100 | 100 kali | 7 kali |
| 1.000 | 1.000 kali | 10 kali |
| 10.000 | 10.000 kali | 14 kali |
| 100.000 | 100.000 kali | 17 kali |
Angka di atas berasal dari pembulatan ke atas logaritma basis dua jumlah commit. Dengan kata lain, repositori besar sekalipun hanya membutuhkan belasan pengujian. Karena itu, git bisect terasa ajaib pada proyek berskala besar atau monorepo yang menerima ratusan commit setiap hari.
Persiapan Sebelum Menjalankan Git Bisect
Hasil git bisect hanya sebaik data yang Anda berikan. Karena itu, siapkan hal berikut sebelum memulai.
- Tentukan commit baik. Cari tag rilis, hash commit, atau tanggal ketika aplikasi masih normal. Perintah
git log --onelinedangit tagmembantu menemukannya. - Tentukan commit buruk. Biasanya ini
HEAD, yaitu kondisi terbaru yang sedang bermasalah. - Siapkan cara uji yang konsisten. Bisa berupa satu perintah tes, satu halaman yang dibuka, atau satu skenario yang mudah diulang.
- Bersihkan working directory. Simpan perubahan lokal dengan
git stashatau commit dulu, karena bisect berpindah-pindah commit. - Pastikan bug bisa direproduksi. Jika bug muncul acak, hasil bisect tidak bisa dipercaya.
Langkah terakhir paling penting. Jika Anda ragu terhadap penilaian sebuah commit, satu keputusan salah saja dapat mengarahkan seluruh pencarian ke commit yang keliru.
Langkah Manual Mencari Commit Penyebab Bug dengan Git Bisect
Alur manual git bisect terdiri dari beberapa perintah sederhana. Berikut urutannya.
git bisect start
git bisect bad # commit saat ini rusak
git bisect good v2.3.0 # tag atau hash yang masih sehat
Setelah dua titik itu ditentukan, Git otomatis berpindah ke commit di tengah rentang. Jalankan aplikasi atau tes Anda, lalu laporkan hasilnya.
git bisect good # jika commit ini normal
git bisect bad # jika commit ini masih bermasalah
Ulangi proses tersebut sampai Git mengumumkan commit pertama yang rusak, lengkap dengan hash, penulis, tanggal, dan pesan commit. Setelah menemukan pelakunya, akhiri sesi dengan perintah berikut.
git bisect reset
Perintah reset mengembalikan repositori ke cabang awal. Jangan lupa menjalankannya, sebab jika tidak, Anda akan tertinggal dalam keadaan detached HEAD di commit lama. Anda juga bisa menyingkat tiga perintah awal menjadi satu baris, yaitu git bisect start HEAD v2.3.0, di mana argumen pertama adalah commit buruk dan argumen kedua adalah commit baik.
Contoh Kasus: Menemukan Commit Penyebab Bug di 1.200 Commit
Bayangkan tim Anda merilis versi 2.3.0 dengan tombol checkout berfungsi normal. Dua minggu kemudian, tombol itu tidak merespons. Antara tag v2.3.0 dan HEAD terdapat 1.200 commit dari belasan kontributor. Membaca semuanya jelas tidak realistis.
Dengan git bisect, alurnya menjadi seperti berikut:
- Anda memulai sesi dan menandai HEAD sebagai bad serta v2.3.0 sebagai good.
- Git memilih commit ke-600, lalu Anda mengujinya dan tombol berfungsi, sehingga Anda menandainya good.
- Git memilih commit ke-900, lalu tombol rusak, sehingga Anda menandainya bad.
- Rentang menyempit terus menjadi 150, 75, 38, 19, dan seterusnya.
- Setelah sekitar 11 pengujian, Git menunjuk satu commit yang mengubah validasi form pembayaran.
Dalam skenario ini, pekerjaan yang mungkin memakan sehari penuh selesai dalam hitungan menit. Selain itu, Anda mendapat bukti yang objektif. Anda tidak lagi bergantung pada dugaan siapa yang terakhir menyentuh modul tersebut.
Otomatisasi Git Bisect dengan git bisect run
Menandai good dan bad secara manual cukup melelahkan jika langkahnya banyak. Untungnya, git bisect mendukung otomatisasi penuh lewat git bisect run. Perintah ini menjalankan script Anda di setiap commit dan membaca hasilnya dari kode keluar (exit status).
git bisect start HEAD v2.3.0
git bisect run ./cek-bug.sh
Aturan kode keluar yang dipakai Git adalah sebagai berikut.
| Kode keluar script | Arti bagi git bisect |
|---|---|
| 0 | Commit sehat (good) |
| 1 sampai 127, kecuali 125 | Commit rusak (bad) |
| 125 | Commit tidak bisa diuji, dilewati (skip) |
| 128 atau lebih | Sesi bisect dibatalkan |
Berikut contoh script sederhana yang membangun proyek lalu menjalankan satu tes.
#!/bin/sh
# cek-bug.sh
make build || exit 125 # gagal build: lewati commit ini
./jalankan-tes.sh checkout # tes gagal = exit 1 (bad)
Perhatikan baris pertama setelah komentar. Jika proyek gagal dibangun, script keluar dengan kode 125 agar commit tersebut dilewati, bukan salah dinilai sebagai penyebab bug. Jangan lupa memberi izin eksekusi pada script dengan chmod +x cek-bug.sh, dan simpan script di luar repositori agar tidak ikut berganti saat Git berpindah commit.
Dengan pendekatan ini, git bisect berjalan tanpa campur tangan. Anda bisa menyeduh kopi sementara Git menyelesaikan puluhan langkah. Selain itu, hasilnya konsisten karena penilaiannya tidak bergantung pada ketelitian manusia.
Menangani Commit yang Tidak Bisa Diuji dengan git bisect skip
Dalam riwayat nyata, tidak semua commit bisa dibangun atau dijalankan. Ada commit yang menyimpan setengah pekerjaan, kehilangan dependensi, atau merusak proses build untuk sementara. Jika Anda menandainya sembarangan, pencarian commit penyebab bug akan melenceng.
Gunakan perintah berikut untuk melewati commit semacam itu.
git bisect skip
Git kemudian memilih commit lain di dekatnya. Meski begitu, terlalu banyak skip bisa membuat Git tidak bisa menunjuk satu commit pasti. Dalam kasus itu, Git menampilkan beberapa kandidat yang bersebelahan, dan Anda perlu memeriksanya secara manual. Karena itu, praktik commit kecil yang selalu bisa dibangun sangat membantu pencarian di masa depan.
Istilah Kustom untuk Bug yang Bukan Regresi
Kata good dan bad terasa janggal ketika Anda mencari perubahan yang bukan bug. Misalnya, Anda ingin tahu commit mana yang membuat aplikasi menjadi lebih lambat, atau kapan sebuah fitur mulai ada. Untuk kasus ini, Git modern mendukung istilah kustom.
git bisect start --term-old=cepat --term-new=lambat
git bisect cepat v2.3.0
git bisect lambat HEAD
Setelah itu, gunakan istilah baru tersebut di setiap langkah. Anda juga bisa memakai istilah umum old dan new tanpa konfigurasi tambahan. Fitur ini mencegah salah paham, terutama saat banyak anggota tim bergantian menjalankan sesi bisect.
Perintah Pendukung yang Berguna Selama Sesi Bisect
Selain perintah utama, ada beberapa perintah yang memudahkan pekerjaan Anda.
git bisect logmenampilkan semua keputusan yang sudah Anda ambil dalam sesi berjalan.git bisect replay namafilemengulang sesi dari log yang disimpan. Perintah ini berguna jika Anda salah menandai satu commit. Edit log, lalu putar ulang.git bisect visualizemembuka tampilan riwayat yang tersisa untuk diperiksa.git bisect resetmengakhiri sesi dan mengembalikan repositori ke keadaan semula.git bisect start --first-parentmengikuti hanya jalur induk pertama, cocok untuk riwayat yang penuh merge.
Menyimpan hasil git bisect log ke berkas juga baik untuk dokumentasi. Anda bisa melampirkannya ke laporan insiden agar rekan tim dapat memverifikasi alur pencarian.
Git Bisect pada Riwayat dengan Merge dan Cabang
Riwayat Git sebenarnya berbentuk graf berarah tanpa siklus, bukan garis lurus. Cabang yang dipecah lalu digabung membuat riwayat bercabang. Untungnya, git bisect dirancang menangani struktur ini dan tetap memilih titik uji yang membagi graf seimbang.
Meski demikian, ada satu hal yang perlu diwaspadai. Jika bug muncul karena kombinasi dua cabang, commit yang ditunjuk bisa berupa merge commit. Artinya, masing-masing cabang sehat sendiri, tetapi bermasalah ketika digabung. Dalam situasi ini, periksa kedua sisi merge dan cari konflik logika yang tidak terdeteksi oleh Git.
Untuk tim yang memakai alur squash atau rebase, riwayat cenderung lebih linear sehingga bisect lebih mudah dibaca. Sementara itu, tim yang sering merge dapat memakai opsi --first-parent agar pencarian fokus pada cabang utama terlebih dulu, lalu menyelam ke cabang fitur jika diperlukan.
Git Bisect Dibanding Git Blame dan Git Log
Git menyediakan beberapa alat untuk menelusuri riwayat. Masing-masing menjawab pertanyaan yang berbeda, sehingga pemilihan alat yang tepat menghemat banyak waktu.
| Alat | Pertanyaan yang dijawab | Cocok untuk |
|---|---|---|
| git bisect | Commit mana yang pertama kali memunculkan perilaku ini? | Regresi dengan rentang commit besar dan cara uji jelas |
| git blame | Siapa yang terakhir mengubah baris ini? | Melacak asal sebuah baris kode tertentu |
| git log -S | Kapan sebuah potongan teks ditambah atau dihapus? | Mencari kapan fungsi atau konstanta muncul atau hilang |
| git log -p | Apa isi perubahan di tiap commit? | Membaca perubahan pada berkas tertentu |
| git revert | Bagaimana membatalkan satu commit dengan aman? | Tindakan setelah commit penyebab bug ditemukan |
Git blame menunjukkan siapa yang terakhir menyentuh sebuah baris, tetapi belum tentu orang itu penyebab bug. Bisa jadi ia hanya merapikan format. Sebaliknya, git bisect menjawab pertanyaan berbasis perilaku, bukan berbasis baris. Karena itu, kedua alat sering dipakai berurutan. Pertama, git bisect menemukan commit pelaku. Kedua, git blame dan git show membantu memahami konteks perubahannya.
Penerapan Git Bisect dalam Tim dan Pipeline CI
Git bisect semakin kuat ketika didukung praktik tim yang baik. Berikut beberapa kebiasaan yang membuatnya lebih efektif.
- Commit kecil dan atomik. Satu commit sebaiknya mengerjakan satu hal. Dengan begitu, commit penyebab bug mudah dipahami setelah ditemukan.
- Jaga build tetap hijau. Setiap commit di cabang utama idealnya bisa dibangun, sehingga jumlah skip minimal.
- Tulis tes regresi. Tes otomatis menjadi dasar script
git bisect run. Praktik ini sejalan dengan continuous integration, yaitu penggabungan kode yang sering disertai pengujian otomatis. - Pesan commit yang jelas. Pesan yang baik mempercepat analisis setelah pelaku ditemukan.
- Dokumentasikan temuan. Simpan log bisect pada laporan insiden agar pelajaran tidak hilang.
Dalam pipeline CI, Anda dapat membuat pekerjaan khusus yang menjalankan bisect otomatis ketika tes di cabang utama gagal. Hasilnya berupa komentar yang menyebut commit tersangka. Meskipun begitu, tetap lakukan verifikasi manual sebelum menyalahkan seseorang atau melakukan revert, karena tes yang tidak stabil dapat menghasilkan tersangka palsu.
Kesalahan Umum Saat Memakai Git Bisect
Beberapa kesalahan berikut sering membuat hasil git bisect tidak akurat atau membingungkan.
- Tes yang tidak stabil. Bug yang muncul acak membuat Anda salah menandai commit. Ulangi tes beberapa kali pada tiap titik, atau perbaiki dulu ketidakstabilannya.
- Salah menentukan commit good. Jika commit yang Anda anggap sehat sebenarnya sudah rusak, Git tidak akan menemukan pelaku yang benar. Verifikasi dulu dengan checkout manual.
- Lupa menjalankan reset. Anda tertinggal di commit lama dan bingung mengapa kode terasa berbeda.
- Mengabaikan perubahan lingkungan. Dependensi, konfigurasi, atau data uji yang berubah dapat memengaruhi hasil tanpa terkait commit mana pun.
- Artefak build lama. Berkas hasil kompilasi dari commit sebelumnya bisa tertinggal. Bersihkan build di setiap langkah jika perlu.
- Meletakkan script uji di dalam repositori. Script bisa berubah atau hilang saat Git berpindah commit. Simpan di luar repositori.
- Menerima hasil tanpa verifikasi. Setelah commit ditemukan, coba revert di salinan lokal atau uji commit sebelumnya untuk memastikan.
Jika Anda ingin memperdalam topik terkait, baca juga panduan dasar Git untuk pemula, Gitignore untuk Pemula: 10 File yang Jangan Masuk Repo, dan Git Worktree: Banyak Fitur Tanpa Pindah Branch 2026.
Pertanyaan yang Sering Diajukan tentang Git Bisect
Apakah git bisect mengubah riwayat atau kode saya?
Tidak. Git bisect hanya berpindah antar commit dan tidak menulis ulang riwayat. Namun, perpindahan itu mengubah isi working directory sementara, jadi simpan perubahan lokal lebih dulu. Setelah selesai, git bisect reset mengembalikan semuanya.
Apakah git bisect bisa dipakai tanpa tes otomatis?
Bisa. Anda cukup menjalankan aplikasi secara manual di tiap titik dan menandainya good atau bad. Meski begitu, tes otomatis dengan git bisect run lebih cepat dan lebih konsisten.
Bagaimana jika saya salah menandai sebuah commit?
Simpan log dengan git bisect log, edit baris yang salah, lalu putar ulang memakai git bisect replay. Anda tidak perlu mengulang seluruh sesi dari awal.
Berapa banyak commit yang masih efisien untuk git bisect?
Hampir tidak ada batas praktis. Karena sifatnya logaritmik, rentang 100.000 commit hanya membutuhkan sekitar 17 langkah. Waktu terbanyak biasanya habis pada proses build dan pengujian, bukan pada pencarian.
Apakah git bisect menunjuk orang yang bersalah?
Git bisect menunjuk commit, bukan niat. Commit itu bisa saja benar secara kode, tetapi memicu bug karena interaksi dengan bagian lain. Gunakan hasilnya sebagai bahan analisis teknis, bukan alat menyalahkan.
Apakah git bisect bisa mencari perubahan selain bug?
Bisa. Dengan istilah kustom, Anda dapat melacak kapan performa menurun, kapan sebuah fitur muncul, atau kapan ukuran berkas membengkak. Tentukan saja apa arti old dan new untuk kasus Anda.
Kesimpulan
Git bisect mengubah pencarian bug yang melelahkan menjadi proses yang cepat dan terukur. Dengan pencarian biner, Anda hanya perlu belasan pengujian untuk menemukan commit penyebab bug, bahkan di repositori yang sangat besar. Kuncinya ada pada tiga hal: titik good dan bad yang benar, cara uji yang konsisten, dan otomatisasi lewat git bisect run.
Mulailah dari kasus kecil di proyek Anda. Pilih satu regresi yang pernah terjadi, tentukan tag yang masih sehat, lalu jalankan git bisect secara manual. Setelah terbiasa, ubah langkahnya menjadi script agar bisa dipakai ulang oleh seluruh tim. Dengan begitu, waktu yang dulu habis untuk membaca diff bisa dialihkan untuk memperbaiki masalah itu sendiri.
Pernahkah git bisect menyelamatkan Anda dari bug yang sulit dilacak? Ceritakan pengalaman Anda di kolom komentar agar pembaca lain bisa belajar.
2 Replies to “Git Bisect: Menemukan Commit Penyebab Bug Tanpa Memeriksa Kode Satu per Satu”