14 Jan 2012

Git bisect

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 wxyz and abcd, do this:

$ git bisect start
$ git bisect good wxyz
$ git bisect bad abcd

You are essentially telling Git to bisect the commits between wxyz and 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
Tagged with:

Leave a Reply