14 Jan 2012
You are part of a large team, and a bug has secretly crept into your codebase. You are on a mission to find out which exact commit caused that bug. I found myself on such a mission recently, and I thought I will write a quick post on how I used the awesome
bisect command to identify the faulty commit quickly.
Let’s assume that the latest git commit id on your master branch is
abcd. Let’s say that you do know that this bug did not exist in the previous release, whose last git commit id is
wxyz. To identify the git commit which introduced this bug, and which lies between
abcd, do this:
$ git bisect start $ git bisect good wxyz $ git bisect bad abcd
You are essentially telling Git to bisect the commits between
abcd. Git will temporarily move you to a new branch called
bisect and will now point to a commit that’s in the middle of both commits.
Bisecting: 34 revisions left to test after this [25d71758dd0e131e9409f3896416eabc81d69ec8] Search field fixes
Verify whether the bug exists at this state. If it still does, type:
$ git bisect bad
Once again, Git will halve the number of commits needed to test by pointing you to a commit that’s right in the middle, between the previous bad commit and the good commit. Continue this process, telling git at each stage, whether a commit is “good” or “bad”, and git will eventually identify the first bad commit.
5bc592ab9065b12bf1bc516ab9e0fe461699971b is the first bad commit
Once you are done figuring out what changes caused the bug, you can return back to your original working state by:
$ git bisect reset