git bisect
Use binary search through commit history to find which commit introduced a bug or regression.
Tests are failing, but they worked fine last week. Somewhere in the past 50
commits, someone introduced a bug. Manually checking each commit would take
hours. git bisect automates the search using binary search, cutting the
problem space in half with each test until it identifies the exact commit that
broke things.
You start by running git bisect start, then mark your current commit as bad
(where the bug exists) with git bisect bad. Next, identify a commit where
things worked—maybe last week's release—and mark it good with
git bisect good v1.2.0. Git checks out a commit halfway between good and bad.
You test whether the bug exists at this commit, then run git bisect good or
git bisect bad based on your findings.
Git repeats this process, each time narrowing the range by half. After a few
iterations (log₂ of your commit count), Git identifies the first bad commit—the
one that introduced the bug. Running git bisect reset returns you to your
original branch.
For automated testing, you can run git bisect run ./test-script.sh, where the
script exits with 0 for good commits and non-zero for bad ones. Git
automatically bisects through commits, running the script each time, and tells
you which commit is the culprit without manual intervention.
In pull request workflows, bisect helps investigate regressions reported after merging. When a feature causes unexpected behavior, bisect pinpoints which PR or commit introduced the issue, even if the problem wasn't noticed until later. This is far more efficient than reading through dozens of commits trying to spot the bug.
Understanding bisect means having a systematic debugging tool for when you know something broke but not when or how. It transforms a potentially hours-long search into a few minutes of binary search, leveraging your commit history to isolate problems.