When something breaks, or you find a bug, it can be helpful to identify the commit which introduced the faulty code. Git comes with the ‘bisect’ command, which makes searching for that commit efficient.
Bisect helps automate a binary search through a series of commits, to find the earliest one which exhibits the problematic behaviour. After providing an initial ‘good’ commit without the bug, and a ‘bad’ commit which contains it, bisect will iteratively guess a commit and automatically check it out for you. After you test this checkout and identify if it is ‘good’ or ‘bad’, Git will guess the next commit, until it has identified the first ‘bad’ commit.
Here is an example of how to use bisect:
$ git bisect start $ git bisect good [commit] # [commit] is the sha1/branch of a 'good' commit $ git bisect bad [commit] # [commit] is the sha1/branch of a 'bad' commit
Git will then checkout its guess, and output the commit information. You should then test the code, and indicate to Git if the commit contains the fault using:
$ git bisect good # OR $ git bisect bad
After a number of iterations Git will output information on the offending commit, ex:
b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit commit b047b02ea83310a70fd603dc8cd7a6cd13d15c04 Author: PJ Hyett Date: Tue Jan 27 14:48:32 2009 -0800 secure this thing :040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730 f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config
You should then run the following command to restore your repository to its state before you ran git bisect:
$ git bisect reset
This post is based off of the following:
http://book.git-scm.com/5_finding_issues_-_git_bisect.html
http://progit.org/book/ch6-5.html