Run git bisect start, mark a bad commit with git bisect bad, mark a good commit with git bisect good , then repeatedly test and mark git bisect good or git bisect bad until Git reports the first bad commit. Automate with git bisect run
Feature / Aspect
Manual Search
Git Bisect
Time for 100 commits
~100 tests (hours)
~7 tests (minutes)
Automation
None
Full with git bisect run
Handles merge commits
Confusing
With --first-parent
Non-deterministic bugs
Can work with retries
Needs stable test
Requires good commit
Yes
Yes
⚙ Quick Reference
6 commands from this guide
File
Command / Code
Purpose
manual_search_vs_bisect.sh
for commit in $(git log --oneline --reverse good..bad | awk '{print $1}'); do
Why Manual Searching Is a Trap
manual_bisect.sh
git bisect start
Running Bisect by Hand
bisect_run.sh
make build 2>/dev/null || exit 125 # skip if build fails
Automating Bisect with a Test Script
handle_merges.sh
git bisect start --first-parent
Handling Merge Commits and Skipping Broken Commits
flaky_test_mitigation.sh
PASS=0
When Bisect Lies
no_checkout_bisect.sh
git bisect start --no-checkout
Bisect on Large Repos
Key takeaways
1
Git bisect finds the exact bug-introducing commit in O(log N) time
always use it for regressions instead of manual searching.
2
Automate with git bisect run and a deterministic test script
this turns hours of debugging into minutes.
3
Use --first-parent to avoid false positives from merge commits, and --no-checkout for large repos.
4
Bisect is useless for non-deterministic bugs
stabilize your test first, or use a different approach.
INTERVIEW PREP · PRACTICE MODE
Interview Questions on This Topic
Q01SENIOR
How does git bisect handle merge commits, and how can you avoid false po...
Q02SENIOR
When would you choose git bisect over git blame for finding a bug?
Q03SENIOR
What happens if you mark a commit as good when it's actually bad during ...
Q04JUNIOR
Explain how git bisect works internally.
Q05SENIOR
You're bisecting a bug that only appears under high load. How do you aut...
Q06SENIOR
How would you design a CI pipeline that automatically bisects regression...
Q01 of 06SENIOR
How does git bisect handle merge commits, and how can you avoid false positives from merges?
ANSWER
By default, bisect follows both parents of a merge, which can point to the merge commit itself. Use --first-parent to only follow the mainline, treating merges as single steps. This avoids false positives from branch history.
Q02 of 06SENIOR
When would you choose git bisect over git blame for finding a bug?
ANSWER
Use bisect when the bug is a regression (worked before, broken now) and you don't know which file or line is responsible. Use blame when you suspect a specific file and want to see who last changed each line. Bisect is for time-based search; blame is for file-based.
Q03 of 06SENIOR
What happens if you mark a commit as good when it's actually bad during a bisect session?
ANSWER
Bisect will converge on a wrong commit — likely a later commit that appears to introduce the bug but actually just exposes the earlier mistake. The fix is to review the bisect log with git bisect log, correct the marks, and replay with git bisect replay.
Q04 of 06JUNIOR
Explain how git bisect works internally.
ANSWER
Git bisect uses binary search on the commit DAG. It calculates the midpoint between good and bad commits using graph theory, then checks out that commit. After each test, it narrows the range. It tracks the search state in .git/BISECT_* files.
Q05 of 06SENIOR
You're bisecting a bug that only appears under high load. How do you automate the test?
ANSWER
Write a script that deploys the commit to a staging environment, runs a load test (e.g., with ab or k6), and checks for the bug symptom (e.g., error rate > 1%). The script must be idempotent and handle cleanup. Use git bisect run with that script.
Q06 of 06SENIOR
How would you design a CI pipeline that automatically bisects regressions?
ANSWER
Store known good commit hashes from passing builds. When a build fails, automatically start a bisect between the last good commit and the current HEAD. Use a test script that runs the same CI checks. Report the first bad commit to the team. This requires deterministic tests and a fast bisect setup.
01
How does git bisect handle merge commits, and how can you avoid false positives from merges?
SENIOR
02
When would you choose git bisect over git blame for finding a bug?
SENIOR
03
What happens if you mark a commit as good when it's actually bad during a bisect session?
SENIOR
04
Explain how git bisect works internally.
JUNIOR
05
You're bisecting a bug that only appears under high load. How do you automate the test?
SENIOR
06
How would you design a CI pipeline that automatically bisects regressions?
SENIOR
FAQ · 4 QUESTIONS
Frequently Asked Questions
01
How do I use git bisect to find a bug?
Run git bisect start, mark the current commit as bad with git bisect bad, mark a known good commit with git bisect good <commit>, then repeatedly test and mark git bisect good or git bisect bad until Git reports the first bad commit. End with git bisect reset.
Was this helpful?
02
What's the difference between git bisect and git blame?
Git bisect finds the commit that introduced a bug by binary search through history. Git blame shows who last modified each line of a file. Use bisect for regressions, blame for finding the author of a specific line.
Was this helpful?
03
How do I automate git bisect with a script?
Write a script that returns 0 for good (bug absent) and non-zero for bad (bug present). Then run git bisect run ./script.sh. The script must be idempotent and not modify the repo.
Was this helpful?
04
What happens if git bisect points to a merge commit?
The bug was introduced in the merge itself or in one of the merged branches. Use git bisect --first-parent to avoid this, or bisect again within the merged branch. Check the merge diff for clues.