git bisect Temukan Komitmen yang Menghancurkan Tanpa Membaca 500 Baris Log

Anda mendorong 50 commit selama dua minggu. Di suatu titik, sesuatu rusak. Uji yang dulu lewat tiga minggu lalu kini gagal. git log --oneline menampilkan 200 baris yang tidak ingin Anda baca.

Anda memiliki pilihan: memandang perbedaan hingga mata Anda mengalir darah, git checkout melakukan commit secara acak dan menguji secara manual, atau menggunakan alat yang sudah ada sejak 2007 dan termasuk dalam setiap instalasi.

git bisect melakukan pencarian biner melalui sejarah commit Anda. Anda menandai satu commit sebagai rusak, satu sebagai berfungsi, dan alat tersebut akan mengeluarkan commit-nya di antara keduanya — membagi ruang pencarian setengah kali setiap kali. Menemukan penyebab dalam 500 commit membutuhkan sekitar 9 langkah. Sebagian besar pengembang tidak pernah menggunakan fitur ini.

Bagaimana itu bekerja

Alur kerja seluruhnya dimulai dengan tiga perintah:

git bisect start
git bisect bad                 # current state is broken
git bisect good v2.4.0         # last known-good tag or commit hash

Git mengeluarkan commit di tengah antara dua titik tersebut. Anda menguji apakah bug ada, lalu memberi laporan kembali:

git bisect good   # bug is NOT present here
# or
git bisect bad    # bug IS present here

Git memotong rentang dan memilih titik tengah berikutnya. Ulangi hingga ia memberi tahu Anda abc1234 is the first bad commit. Saat Anda selesai:

git bisect reset  # returns you to your original branch

Tidak ada flag khusus, tidak ada konfigurasi, tidak ada plugin. Bekerja pada repositori apa pun, pada versi git yang kemungkinan besar Anda miliki.

Sesi Bisect Nyata (Ditandai)

Berikut adalah sesi lengkap. Fungsi yang sebelumnya mengembalikan JSON yang benar mulai mengembalikan null setelah beberapa refactor terbaru — tidak ada pelaku yang jelas dalam commit terbaru:

$ git bisect start
$ git bisect bad HEAD              # current commit is broken
$ git bisect good 3f8a12b          # commit from 2 weeks ago, worked fine

Bisecting: 24 revisions left to test after this (roughly 5 steps)
[c9e41f0] Refactor: extract auth middleware

$ npm test -- --grep "parseResponse"   # ← run your check here
# FAIL
$ git bisect bad

Bisecting: 12 revisions left to test after this (roughly 4 steps)
[a77b2d1] Fix: update retry logic in fetch wrapper

$ npm test -- --grep "parseResponse"
# PASS
$ git bisect good

Bisecting: 6 revisions left to test after this (roughly 3 steps)
[91e0bc3] Refactor: consolidate response handlers

$ npm test -- --grep "parseResponse"
# FAIL
$ git bisect bad

Bisecting: 2 revisions left to test after this (roughly 2 steps)
[b44c19f] Chore: remove deprecated serialization helpers

$ npm test -- --grep "parseResponse"
# FAIL
$ git bisect bad

Bisecting: 1 revision left to test after this (roughly 1 step)
[8d3e77a] Fix: normalize response envelope for new API version

$ npm test -- --grep "parseResponse"
# PASS
$ git bisect good

91e0bc3e1f4d is the first bad commit
commit 91e0bc3e1f4d
Author: Dev <dev@example.com>
Date:   Mon Apr 14 11:23:07 2026

    Refactor: consolidate response handlers

 src/http/response.js | 14 +++---

$ git bisect reset   # ← always do this when done

5 langkah di rentang 50 commit. Commit yang bernama "menggabungkan tangan penanganan respons" secara diam-diam menghapus panggilan serialisasi yang digunakan oleh sesuatu di bawah sistem. Tanpa bisect, Anda akan membaca perbedaan selama satu jam.

Mengotomatiskan Ini

Jika Anda dapat menyatakan pengecekan sebagai skrip — keluar dengan kode 0 jika baik, kode non-nol jika buruk — git bisect dapat berjalan sepenuhnya tanpa intervensi:

git bisect start
git bisect bad HEAD
git bisect good v2.4.0
git bisect run npm test -- --grep "parseResponse"

Git mengeluarkan setiap titik tengah, menjalankan skrip, dan melaporkan commit pertama yang buruk. Untuk uji yang berlangsung kurang dari 10 detik, ini cukup cepat untuk Anda pergi dan kembali dengan jawaban.

Semantik kode keluar untuk skrip pelaksanaan:

• 0 — commit baik
• 1–124 — commit buruk
• 125 — lewatkan commit ini (build rusak, tidak bisa diuji)

Uji dengan validator: 125 ketika commit tidak bisa dikompilasi atau infrastruktur uji rusak di titik tersebut — bisect melewatinya dan beralih ke kandidat berikutnya.

Kapan Bisect Menang Atas git blame

git blame mengatakan siapa yang terakhir mengubah suatu baris. Berguna ketika Anda sudah tahu baris mana yang salah. git bisect digunakan ketika Anda tidak tahu — ketika gejala bersifat perilaku dan penyebabnya bisa berada di mana saja.

Gunakan bisect ketika:

• Anda dapat mereproduksi regresi tetapi tidak dapat mengidentifikasi file tertentu yang menyebabkannya
• Perilaku produksi berubah tetapi tidak ada pelaku yang jelas dalam sejarah terbaru
• "Ini bekerja di versi 2.3, rusak di versi 2.5" dengan 80+ commit di antaranya
• Uji mulai gagal secara konsisten sekitar tanggal tertentu

Ketika membandingkan output antara dua commit selama bisect, menempelkan keduanya ke dalam alat perbandingan teks sering lebih cepat daripada membaca perbedaan terpadu di terminal — terutama ketika output berupa blob JSON atau objek terserialisasi.

Geniş Ortamda Kullanılan Karşılaşmalar

Jangan lupa git bisect reset. Bisect mengeluarkan commit dalam keadaan HEAD terlepas. Jika Anda beralih cabang selama sesi tanpa mereset, status bisect akan menjadi usang dan Anda akan bingung. Selalu reset saat selesai, bahkan setelah menemukan jawabannya.

Commit gabungan dapat memengaruhi rentang. Jika rentang Anda mencakup cabang fitur yang berlangsung lama yang telah digabungkan, bisect mungkin akan berada di dalam commit-cabang tersebut dalam urutan yang tidak jelas. Jalankan git log --oneline --no-merges good..bad pertama untuk memahami apa yang ada di rentang tersebut.

Ketahanan uji adalah segalanya. Jika pengecekan Anda tidak stabil — tergantung waktu, tergantung lingkungan, atau mengakses layanan eksternal — bisect akan memberikan hasil yang buruk. Pastikan uji tersebut deterministik sebelum mengotomatiskannya.

Commit yang diidentifikasi oleh bisect adalah titik di mana perilaku berubah, bukan pasti tempat bug berada. Kadang-kadang refactor yang benar mengungkap asumsi yang sudah ada di tempat lain. Pertimbangkan hasilnya sebagai "mulai baca di sini", bukan "kembalikan ini dan Anda selesai."

Jika Anda sering memperbaiki sejarah git, halaman IO Tools memiliki bisect, blame, log flags, dan reflog semuanya dalam satu halaman — layak dijadikan bookmark saat sesuatu yang misterius rusak. Lembar Cheat Git git bisect: Temukan Commit yang Menghancurkan Tanpa Membaca 500 Baris Log 2

Anda mungkin juga menyukai