🔍 CHAPTER · GIT BISECT
Chef You

Binary Search
for Bugs

Something broke — but when? Instead of checking every commit, git bisect uses binary search to find the exact guilty commit in just a few steps.

Scene I

The detective algorithm

Chef You

You have 16 commits. The bug is somewhere in the middle. Checking all 16 would take ages.

Binary search: Git checks the middle commit. You tell it: GOOD or BAD. Git cuts the search space in half. Repeat. In just 4 steps, you find the exact buggy commit out of 16. That's log₂(16) = 4.

🔍 BISECTING Step 0 — Is this commit good or bad?
Bug Found!

🎉 Commit ??? broke it

Out of 16 commits, you found the guilty one in just 4 steps. That's the power of binary search — O(log n).

In a real project with 1000 commits, bisect would find the bug in just ~10 steps instead of checking all 1000.

$ git bisect start
$ git bisect bad # current is broken
$ git bisect good v1.0 # this was fine
Bisecting: 8 revisions left
$ git bisect good
Bisecting: 4 revisions left
e7b2d18 is the first bad commit
Epilogue
Bisect = binary search on commits.
Find the bug in O(log n) steps.
Genius debugging.

Pro tip: you can even automate bisect with a test script — git bisect run ./test.sh runs the entire search automatically.