How to bisect commits in Git
Łukasz Holeczek
Follow Łukasz Holeczek on GitHub
Connect with Łukasz Holeczek on LinkedIn
Follow Łukasz Holeczek on X (Twitter)
Finding which commit introduced a bug becomes increasingly difficult as your commit history grows, especially when the bug was introduced weeks or months ago. With over 25 years of software development experience and as the creator of CoreUI, I’ve tracked down countless elusive bugs in large codebases. Git bisect uses binary search to efficiently identify the problematic commit by testing commits between a known good state and a known bad state. This approach can find the bug-introducing commit in just a few steps, even with hundreds of commits in between.
Use git bisect to perform binary search through commits and identify when a bug was introduced.
# Start bisect session
git bisect start
# Mark current commit as bad (has the bug)
git bisect bad
# Mark a known good commit (before the bug existed)
git bisect good v1.2.0
# Git checks out a commit halfway between good and bad
# Test your application, then mark it:
git bisect bad # if bug exists
# or
git bisect good # if bug doesn't exist
# Repeat until Git identifies the first bad commit
# Git will show: "X is the first bad commit"
# Exit bisect and return to original HEAD
git bisect reset
For automated testing:
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
# Run automated test script
git bisect run npm test
# Git automatically finds the first bad commit
git bisect reset
Best Practice Note
The bisect run command accepts any script that exits with 0 for success (good commit) and non-zero for failure (bad commit). This automates the entire bisect process without manual testing. For large histories, bisect typically needs only log2(n) steps—finding the culprit in 1000 commits takes just 10 steps. This is the same technique we use in CoreUI development when a regression appears but we’re unsure which of the recent 50+ commits caused it.
