Hunting Bugs with git bisect

"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.

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.

📋 Quick Reference

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

Practice quiz

What problem does git bisect solve?

  • Merging branches
  • Recovering deleted files
  • Finding the exact commit that introduced a bug via binary search
  • Renaming branches

Answer: Finding the exact commit that introduced a bug via binary search. git bisect binary-searches your history to pinpoint the first commit where a bug appeared.

Which command starts a bisect session?

  • git bisect start
  • git bisect run
  • git bisect begin
  • git bisect init

Answer: git bisect start. git bisect start opens a session; you then mark a good and a bad commit.

After 'git bisect start', what two markers do you give Git?

  • A branch and a tag
  • Two file paths
  • An author and a date
  • One known-good commit and one known-bad commit

Answer: One known-good commit and one known-bad commit. You mark a bad commit (bug present) and a good commit (bug absent) to bound the search.

Roughly how many tests does bisect need across 1,000 commits?

  • About 1,000
  • About 10
  • About 500
  • Exactly 2

Answer: About 10. Binary search needs about log2(N) steps — roughly 10 tests for 1,000 commits.

What does 'git bisect run <script>' do?

  • Automates bisect by using the script's exit code at each step
  • Runs the bug
  • Runs all commits at once
  • Reverts the bad commit

Answer: Automates bisect by using the script's exit code at each step. git bisect run executes your script at each step: exit 0 means good, non-zero means bad.

In a bisect run script, what exit code marks a commit as BAD?

  • 0
  • 125
  • Any non-zero code (except 125)
  • -1 only

Answer: Any non-zero code (except 125). Exit 0 = good, non-zero = bad. Exit 125 specially means 'skip / cannot test this commit'.

What does exit code 125 mean to git bisect run?

  • Bad commit
  • Skip this commit — it can't be tested
  • Good commit
  • Abort the bisect

Answer: Skip this commit — it can't be tested. 125 tells bisect the commit is untestable, so it skips it like git bisect skip.

What MUST you run when the bisect is finished?

  • git bisect end
  • git bisect stop
  • git checkout main
  • git bisect reset

Answer: git bisect reset. git bisect reset returns you to your original branch and ends the session cleanly.

If a commit can't be built or tested, which command skips it?

  • git bisect ignore
  • git bisect skip
  • git bisect pass
  • git bisect next

Answer: git bisect skip. git bisect skip moves past an untestable commit so bisect keeps narrowing the range.

What does bisect print when it finishes?

  • 'all commits are good'
  • 'merge complete'
  • '<hash> is the first bad commit'
  • nothing

Answer: '<hash> is the first bad commit'. Bisect reports the first bad commit, with its diff, so you know exactly what introduced the bug.