Git bisect for finding the commit that introduced a bug

Git bisect runs a binary search across commit history to find which commit introduced a regression. It is the correct tool when a bug exists in the current HEAD, did not exist at some known-good point, and reading 80 commits of diff would take hours.

The binary search workflow

• Mark a known-bad commit: git bisect bad HEAD; mark a known-good commit: git bisect good v2.4.0; bisect checks out the midpoint commit for you to test
• Test the checked-out version — compile, run the failing test, or hit the endpoint — then tell bisect git bisect good or git bisect bad; it halves the remaining search space and checks out the next midpoint
• Seven rounds of bisection cover 128 commits; finding the culprit among 80 weekend commits takes about 7 rounds instead of reading all 80 diffs

Automating bisect with a test script

• git bisect run mvn test -pl :order-service -Dtest=OrderServiceTest automates the entire bisection — bisect runs the command at each midpoint and treats exit code 0 as good, non-zero as bad
• The test must be deterministic; a flaky test produces a false bad result that misdirects bisect to an innocent commit
• Write the reproduction test before starting bisect — having a precise, isolated test is what makes automation possible and the result reliable

After finding the culprit commit

• git bisect reset returns the repository to the original HEAD after the search completes
• Examine the identified commit with git show — the diff will be small (bisect found a specific commit, not a range) and the bug is usually obvious in context
• git log --oneline .. lists all commits in the bad range if you want to understand what changed in that window before bisect narrows it down