Have you heard about git-bisect? Well, if you haven’t, let me tell you that this command is a powerful GIT debug tool to find a change which has introduced a bug somewhere in the history of a GIT tree. The power of this command resides in the fact that it uses a binary search algorithm to locate the position of the element in a delimited change set. In my opinion, “git bisect” is one of the best feature that the GIT version control offers.

How to use “git bisect”?

To see the git-bisect manual page click here.

Git-bisect will drive a binary search to find the version where the bug was introduced.

To find more help about this tool you can type the following in command line:

$ git bisect help

To use this tool you need to identify two points of reference, a good revision and a bad revision, then you will provide the commits IDs for each of the “rev” values listed below:

$ git bisect start [<bad> [<good>...]] [--] [<paths>...]
$ git bisect bad [<rev>]
$ git bisect good [<rev>...]

<Run your tests and evaluate. Repeat these steps to narrow down which of the commits was the problem>

Other useful subcommands are the following:

$ git bisect skip [(<rev>|<range>)...]
$ git bisect reset [<commit>]
$ git bisect visualize
$ git bisect replay <logfile>
$ git bisect log

If you really want to automate this process you may want to explore more about the following subcommand:

$ git bisect run <cmd>...

How “git bisect” works?

Let’s considered a change set as an array R of N elements with an attribute Commit. Elements 1 to N ordered on the position of Commit, such that:

A and B will be our boundaries where A=<good commit>=0 and B=<bad commit>=N+1. The following flowchart represents the process follow by git-bisect: