Shreyansh Jain.

Software engineer and IIT Roorkee alumnus. I write about programming, computer science, and the things I learn while building software.

Shreyansh Jain
Git Series Sep 10, 2023 3 min read

Git Bisect

git bisect is a handy tool for pinpointing the exact commit that introduced a bug into your code. It works by systematically narrowing down the range of commits between a known "working" state and a known "broken" state, using binary search.

The Problem It Solves


Suppose you need to find the commit that introduced a bug. The naive approach is to check out commits one by one and test each one, which is slow and tedious. A slightly better approach is to list all the commits between the good and bad states and binary-search through them manually.
But you don't have to do either of these by hand: git bisect does it for you.

The Commands



  • git bisect start: starts the bisect process

  • git bisect good : marks the given commit as good

  • git bisect bad : marks the given commit as bad

  • git bisect good: marks the current commit as good

  • git bisect bad: marks the current commit as bad

  • git bisect reset: ends the bisect process and returns you to your original branch


Walking Through an Example


Suppose we know the code was working fine at the first commit (commit 1, hash fadce01), but broken by the seventh (commit 7, hash 3c4fede). Here's how we'd use git bisect to find the exact commit that introduced the bug:
!Initial state: commit 1 is good, commit 7 is bad
1. Start the process and tell Git the boundaries: mark the first commit (fadce01) as good and the seventh (3c4fede) as bad:
   git bisect start
git bisect good fadce01
git bisect bad 3c4fede

!After git bisect start: Git checks out the middle commit, 4
Git automatically checks out the commit in the middle of that range (commit 4) for you to test.
2. We test commit 4 and it turns out to be good:
   git bisect good

!Commit 4 tested good: range narrows to the right half, Git checks out commit 6
Git now knows everything up to and including commit 4 is fine, so it narrows the range and checks out commit 6.
3. We test commit 6 and it's bad:
   git bisect bad

!Commit 6 tested bad: range narrows between 4 and 6, Git checks out commit 5
The bug must lie somewhere between commit 4 (good) and commit 6 (bad). Git checks out commit 5, the only one left to test.
4. We test commit 5 and it's bad too:
   git bisect bad

!Commit 5 tested bad: result is commit 5 introduced the bug
Since commit 4 was good and commit 5 is bad, with nothing left in between, we've confirmed: commit 5 introduced the bug.
5. Once you've found the culprit, exit the bisect process and return to where you started:
   git bisect reset

Why It's Worth Using


Because git bisect uses binary search instead of a linear scan, the number of steps needed grows only logarithmically with the number of commits. The more commits you have between good and bad, the more time you save. It's a genuinely useful tool for hunting down regressions, and I'd recommend adding it to your workflow.

Enjoyed this essay?

Support my writing by buying me a coffee.