Git Bisect: The Binary Search Story

This will be a short one; in this article, we will talk about another great utility of git, i.e. git bisect. Git has never stopped astonishing me as a developer with its unlimited and effective utility commands that binds some super level of engineering done at the back of it whether it be the git patches, cherry-pick, stash, or hooks. Recently I came across this command called git bisect, and I personally find it very useful, at the time for the specific use case, but now as well; thinking about its application.

So, I recently started working on a different module, a huge one with complex and complicated code architecture, hence was subjected to a lot of code changes even for a tiny requirement to fulfill. I was working on fixing a bug that was reported a few months back, but when I dived deep into the code, I realized that the bug was created long back, but it was not reported by the customers. I started finding the entry point of the bug, but since I wasn’t a part of that module, I didn’t know when it was introduced, and with tons of lines of code getting pushed, it was difficult for me to find out when was the bug introduced. (Seems like a DSA question if we really think this through). One of my colleagues mentioned this command and said maybe you can use git bisect. I gave it a read and tried to solve my problem using git-bisectand indeed it’s a great find.

Git Bisect (According to the official documentation) uses binary search to find the commit that introduced a bug.

Now, as we know, this command allows us to run down through our commit/project history, in a binary search fashion to find the entry-point of the bug.

Description

Generic: git bisect <subcommand> <options>

git bisect start [--term-{new,bad}=<term> --term-{old,good}=<term>]
   [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<paths>...]
git bisect (bad|new|<term-new>) [<rev>]
git bisect (good|old|<term-old>) [<rev>...]
git bisect terms [--term-good | --term-bad]
git bisect skip [(<rev>|<range>)...]
git bisect reset [<commit>]
git bisect (visualize|view)
git bisect replay <logfile>
git bisect log
git bisect run <cmd>...
git bisect help

When we think about how it works like; we have to tell it a bad commit that contains a bug, and a good commit that existed before the bug was introduced. Once this is done, git bisect will find a commit in between them and will ask you if it’s the good one or bad one, hence narrowing down the sample space by half everytime until we find the exact commit which introduced the change.

A Dry-run of above paragraph looks like this:

We go to a point back in time, when we suppose the bug was not there, 
and checkout to that commit.

$ git checkout <commit>


Then we start git bisect using this command and mark it as good or bad, 
according to the use case.(Instead of checking out to specific commit, 
we can also pass commit in git bisect good/bad command itself)

$ git bisect start
$ git bisect good

  Bisecting: 675 revisions left to test after this (roughly 10 steps)

Then git will ask for responses subsequently if the commit is good or bad...
If the next version is good mark good, else bad.

$ git bisect bad
.
.
.

Keep repeating the process: compile the tree, test it, and depending on 
whether it is good or bad run git bisect good or git bisect bad to ask for 
the next commit that needs testing.

Eventually there will be no more revisions left to inspect, and the command 
will print out a description of the first bad commit. 
The reference refs/bisect/bad will be left pointing at that commit. 

Git bisect has other terms as well which are sometimes more relevant than marking commits as good or bad; as sometimes you might be looking for a change that happen instead of a breakage/bug, in that case we can use git bisect old and git bisect new.

There are a lot of use cases that can be covered using git bisect, and I just discussed one of them through this article. Hope it was enough to make git-bisect an interesting topic to be read and dived deep in. You can find more about it here.

Thanks for the read. Keep Growing, Keep learning!