Day 6intermediateFeb 6, 2026

Find the Exact Commit That Broke Your Code with Git Bisect

Git bisect binary-searches through 1,000 commits to find the broken one in just 10 steps.

gitdebuggingtroubleshooting
Share:

What

Git bisect performs a binary search through your commit history. You mark a known good commit and a known bad commit, then Git checks out the midpoint for you to test. Each step cuts the remaining commits in half, so even 1,000 commits only takes ~10 steps to find the bug.

Why It Matters

When something breaks and you have hundreds of commits since the last known good state, manually checking each one is impractical. Git bisect makes finding regressions fast and systematic, even in large codebases with many contributors.

Example

# Start bisecting
git bisect start

# Mark current commit as bad (has the bug)
git bisect bad

# Mark a known good commit (before the bug)
git bisect good v1.2.0

# Git checks out a middle commit β€” test it!
# Then mark it:
git bisect good  # if this commit works
git bisect bad   # if this commit is broken

# Repeat until Git finds the exact commit
# When done:
git bisect reset
bash

Common Mistake

Forgetting to run `git bisect reset` when done. This leaves your repo in a detached HEAD state at some random commit, which leads to confusion later.

Quick Fix

Always end with `git bisect reset` to return to your original branch. You can also automate the whole process with `git bisect run <test-script>` to let Git test each commit automatically.

Key Takeaways

  • 1Bug somewhere in 1,000 commits?
  • 2git bisect start β†’ mark good and bad
  • 3Git checks out the middle commit
  • 4Mark good/bad β†’ repeat (binary search)
  • 5~10 steps to find the bug. git bisect reset when done

Was this tip helpful?

Help us improve the DevOpsPath daily collection

Share: