Hunting Bugs with git bisect

Reviewed & published by Brayan K

"It worked last week, it's broken now, and there are 300 commits in between." By the end of this lesson you'll use git bisect to binary-search your history and pinpoint the exact commit that introduced a bug — often in under ten checks, and fully automated.

Learn Hunting Bugs with git bisect in our free Git course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a quick…

Part of the free Git course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

What You'll Learn

1️⃣ Starting a Bisect

Tell Git two things: a bad commit where the bug exists, and a good commit where it didn't. Git then checks out a commit halfway between them and asks you to test it. Each answer halves the range, so even hundreds of commits resolve in about log₂(n) steps.

2️⃣ Answering good / bad

At each stop, build and test the checked-out commit, then report the result. Git keeps narrowing until one commit remains and announces it as the first bad commit . Whatever happens, finish with git bisect reset to return to your original branch.

3️⃣ Automating with bisect run

The real power is git bisect run . Give it a command whose exit code decides the verdict — 0 for good, non-zero for bad — and Git tests every midpoint itself, hands-free. Your project's test suite is the perfect script. The special code 125 tells bisect to skip an untestable commit.

Your turn. Drive a full automated bisect from start to reset. Fill in the three blanks.

Common Errors (and the fix)

• Stuck on a detached HEAD after bisecting: you forgot to finish. Run git bisect reset to return to your original branch.
• bisect run always reports the same commit: your script's exit code is backwards. Confirm it exits 0 when the bug is absent and non-zero when present.
• "You need to start by 'git bisect start'": you marked good/bad before starting. Run git bisect start first.
• A midpoint commit won't compile: don't mark it bad — that pollutes the result. Use git bisect skip (or exit 125 in a run script).
• Good and bad swapped: if you mark the old commit bad and the new one good, bisect searches the wrong direction. The newer/broken commit is bad .

Pro Tips

• 💡 One-line start: git bisect start <bad> <good> sets both bounds at once.
• 💡 Make a tiny repro script: a focused test runs far faster than the whole suite at each step.
• 💡 See the trail: git bisect log records your answers; git bisect replay reruns them.
• 💡 Visualize progress: git bisect visualize shows the remaining suspect commits.

📋 Quick Reference

Command

Purpose

git bisect start

Begin a bisect session

git bisect bad / good

Mark the current commit broken / working

git bisect run cmd

Automate using a script's exit code

git bisect skip

Skip an untestable commit

git bisect reset

End the session, restore your branch

git bisect log / replay

Record / re-run your answers

Frequently Asked Questions

Mini-Challenge: Catch the Regression

No commands given this time — just the plan. Run a fully automated bisect and name the commit that introduced a bug.

🎉 Lesson Complete!

• ✅ git bisect binary-searches history to find the first bad commit
• ✅ Bound the search with one good and one bad commit
• ✅ Answer good / bad at each midpoint, or automate with bisect run
• ✅ Exit codes: 0 = good, non-zero = bad, 125 = skip
• ✅ Always end with git bisect reset
• ✅ Next lesson: tailor Git to you with configuration and time-saving aliases

Practice quiz

Continue this course

• Previous: Finding Who Changed What with git blame
• Next: Git Configuration & Aliases