git bisect is Git’s built-in “binary search” wizard for hunting down which exact commit introduced a bug.

Git Bisect.md

git bisect is Git’s built-in “binary search” wizard for hunting down which exact commit introduced a bug.

Instead of you guessing and checking commits one-by-one like a caveman with a keyboard, git bisect repeatedly checks out a commit halfway between a known-good state and a known-bad state. You test that commit, tell Git “good” or “bad,” and it halves the search space again. In about log₂(N) steps, you land on the first bad commit.

When you use it • A bug exists now (bad) • You know a point in history where it didn’t exist (good) • You want the first commit that made it break

Typical workflow (manual testing)

git bisect start
git bisect bad                 # current commit is bad
git bisect good <good_commit>  # last known good commit hash/tag

# Git checks out a midpoint commit.
# You run your test (manual or automated), then mark it:
git bisect good                # if the bug is NOT present here
# or
git bisect bad                 # if the bug IS present here

# Repeat until Git prints the first bad commit.
git bisect reset               # return to your original branch/HEAD

Best practice: automate it

If you have a reliable test command that returns exit code 0 = pass and non-zero = fail, you can let Git drive:

git bisect start
git bisect bad
git bisect good <good_commit>
git bisect run <your_test_command>
git bisect reset

Example:

git bisect run dotnet test

Handy details • git bisect skip — if a commit can’t be tested (won’t build, missing dependency, etc.). • Works best when the bug is deterministic and your test is fast. • The result is usually “ is the first bad commit” plus the commit message.