git-bisect-debugging

Git bisect uses binary search to identify the exact commit that broke your code. It systematically narrows the commit range by testing midpoints, requiring you to mark each as good or bad until the culprit is found.

Yes, git bisect supports scripted verification through test automation, manual checks, or hybrid workflows. You can supply a test script to automatically evaluate each commit, or manually verify and mark commits as the bisect progresses.

Binary search via git bisect is the fastest approach, reducing 50 commits to roughly 6 test iterations. Combined with automated verification scripts, you isolate the regression-causing commit without testing every intermediate change.

You need a Git repository with a known good commit (before the bug) and a known bad commit (after the bug). The Skill handles the rest, walking you through strategy selection, verification, and root-cause handoff in a structured four-phase process.

Use git bisect when the bug spans more than a few commits or you need certainty about the exact culprit. Manual review becomes inefficient beyond ~10 commits; bisect's logarithmic search saves time and eliminates guesswork across larger windows.

Automated workflows run test scripts on each commit, returning pass/fail without human judgment. Manual workflows require you to verify and classify each commit. Hybrid approaches combine both, using automation where reliable and manual checks for edge cases.