How to find bugs with Git bisect
Łukasz Holeczek
Follow Łukasz Holeczek on GitHub
Connect with Łukasz Holeczek on LinkedIn
Follow Łukasz Holeczek on X (Twitter)
Tracking down when a specific bug was introduced becomes challenging when you have hundreds of commits and no clear indication of the breaking change. As the creator of CoreUI with over 25 years of software development experience, I’ve used Git bisect to find countless subtle regressions in production codebases. Git bisect combined with automated tests creates a powerful debugging workflow that pinpoints the exact commit introducing the bug. This approach is far more efficient than manually checking out and testing individual commits.
Combine Git bisect with automated test scripts to automatically identify the commit that introduced a bug.
# Create a test script that reproduces the bug
# test-bug.sh
#!/bin/bash
npm test -- --testNamePattern="user authentication"
exit $?
Make it executable:
chmod +x test-bug.sh
Run bisect with automated testing:
# Start bisect
git bisect start
# Mark current state (bug exists)
git bisect bad
# Mark last known good commit
git bisect good abc1234
# Let Git automatically find the bad commit
git bisect run ./test-bug.sh
# Git will output: "X is the first bad commit"
# View the commit details
git show
# Clean up
git bisect reset
For more complex scenarios:
# Skip commits that can't be tested (e.g., won't build)
git bisect skip
# Visualize bisect progress
git bisect visualize
Best Practice Note
Your test script must exit with code 0 for passing (good) and 1-127 (except 125) for failing (bad). Exit code 125 tells bisect to skip that commit. Keep test scripts fast—bisect may run them 10-15 times. You can bisect on any measurable criteria, not just tests: performance regressions, build failures, or visual changes. This is how we maintain CoreUI quality—when a regression appears in our extensive component library, bisect with automated tests identifies the problematic commit within minutes.
