In a collaborative development environment sometimes it becomes difficult to find out in which commit (or check-in) a particular issue was introduced. git bisect is one way to find out the faulty commit. This is an in-built functionality of the version control system git. The procedure is quite familiar among Linux kernel devs. Note that svn has a similar option named svn-bisect.
The working principle of git bisect is simple – it’s like a binary search on a sorted list. You tell git a (good) revision where a certain functionality worked and another (bad) revision where it doesn’t. git automatically checks out the intermediate revision for you. You test and find out if the functionality works there.
Start a git-bisect session:
$ git bisect start $ git bisect bad # Current version is bad $ git bisect good v1.1.1 # v1.1.1 was the last version tested OK
You’ll see an output like
Bisecting: 47 revisions left to test after this
The revision in the middle is then checked-out. Test it. Depending on whether the functionality works or not you mark it as good or bad. For example:
$ git bisect bad
The output should be something like
Bisecting: 23 revisions left to test after this
Keep repeating the process till you find the rogue commit. Once done, reset your branch to the revision you were (before issuing git bisect start) using:
$ git bisect reset