Bisection is binary search applied to debugging. Instead of inspecting every possibility, you repeatedly split the search space in half and ask “is the problem before or after this point?” Each test eliminates half the candidates, so even hundreds of commits or config lines collapse to a handful of checks.

You bisect across time (which commit introduced the bug?), space (which half of the config/file?), and components (disable half the services). Git automates the commit case with git bisect: you mark a known-good and a known-bad commit, and it checks out the midpoint for you to test.

git bisect start
git bisect bad                 # current commit is broken
git bisect good v1.2.0         # this old tag worked
# Git checks out the midpoint — test it, then:
git bisect good                # or: git bisect bad
# ...repeat until Git names the first bad commit...
git bisect reset               # return to where you were

Non-code bisection: comment out half a config, retest; if fixed, the problem was in that half — narrow again.

1. Use git bisect on a repo to find a commit that introduced a change.
2. Describe how you’d bisect a 200-line config file to find a bad setting.
3. Calculate how many steps it takes to bisect 256 candidates.
4. Explain when bisection beats reading code top-to-bottom.

• ↗ git bisect documentation