Finding the Needle in the Haystack
Imagine this scenario: your application worked perfectly three weeks ago. Today it has a critical bug. There are 400 commits between "working" and "broken." Checking each commit one by one would take hours.
git bisect solves this with a binary search through commit history. Binary search is the algorithm where you repeatedly cut the search space in half — instead of checking 400 commits, you check at most log₂(400) ≈ 9 commits to find the culprit.
How It Works
You tell Git two boundary points: a commit known to be broken and a commit known to still be good. Git checks out the commit exactly halfway between the two. You test it — run your test suite, reproduce the bug manually, whatever is appropriate — then tell Git whether that midpoint was good or bad. Git eliminates half the remaining commits and checks out the new midpoint. After 8-9 rounds, Git announces exactly which commit introduced the regression, down to its author, timestamp, and message.
Automating Bisect
If you have a test script that exits with code 0 for "good" and non-zero for "bad", the entire process can be automated: point bisect at the script instead of testing manually, and Git runs it at each midpoint, using the exit code to classify commits automatically. This can find the offending commit in seconds with no manual intervention.
Key Point:
git bisectuses binary search to find the commit that introduced a bug in O(log n) steps instead of O(n). Automating it withgit bisect runmakes it a powerful regression-finding tool that requires no manual intervention.