Why do small, individually buildable commits make git bisect far more useful?

## Resolution is one commit Bisect performs a binary search over the commit graph and stops at a boundary: the first commit, in the searched range, where the symptom is present. That is the finest answer it can give. How useful the answer is therefore comes down entirely to what one commit contains in your repository. If your commits are small and single-purpose, `<sha> is the first bad commit` is close to a complete diagnosis: a diff of a few dozen lines with a message explaining intent. If your history consists of one commit per feature branch containing a week of work across forty files, bisect has done its job perfectly and told you almost nothing you did not already know. The search cost is logarithmic; the payoff is proportional to commit size. ## Every candidate must be judgeable The second requirement is that an arbitrary commit in the range can be built and tested. Bisect does not walk your history in the order you wrote it — it jumps to whichever commit sits near the middle of the remaining candidate set. That commit might be a mid-refactor state, a commit that renames a file before the callers are updated, or a work-in-progress step inside a topic branch. Every such commit costs you: you answer `git bisect skip` (or, in `git bisect run`, the script exits `125`), Git picks a neighbour instead of halving cleanly, and the search takes more steps. If enough commits are unjudgeable, the search can end without a single answer, reporting a set of commits the first bad one could be. A history where any commit builds is what keeps bisect logarithmic and unambiguous. ## Automation raises the bar further `git bisect run` only pays off when one command can decide the question at any commit. That requires two things from history: the build works at each candidate, and the test that reproduces the symptom exists — or can be supplied from outside the repository — across the range. Teams that keep commits atomic and green get unattended searches; teams that do not end up hand-testing every step. ## The merge-topology angle A history full of merged branches contains many commits that were only ever meant to be valid as part of a completed branch. Recent Git offers `git bisect start --first-parent`, which follows only first parents so the search stays on the mainline and names the merge that brought the regression in. That is a coarser answer — a whole branch rather than a commit — but a reliable one, and it is the natural fallback when intermediate commits are not individually buildable. ## The practical hygiene rules What this implies for day-to-day work: - Keep each commit to one logical change, so the boundary commit is readable. - Keep each commit buildable and testable on its own, so no step is wasted on a skip. - Write messages that say why, so the reported commit explains itself without archaeology. - Keep unrelated formatting or bulk renames in separate commits, so the guilty diff is not buried in noise. ## Limiting the search another way When commits are large for historical reasons you can still narrow the field: `git bisect start -- <path>` restricts candidates to commits touching the given paths, so the search visits fewer, more relevant commits. It reduces steps, but it cannot make an individual commit smaller — only commit hygiene does that. ## Why interviewers ask it The question connects two things candidates often treat separately: how they write commits, and how fast their team diagnoses regressions. Answering it well means saying explicitly that commit granularity is the resolution limit of your debugging tools, not a matter of taste.