Git bisect – Improve your bug detective skills with this cool command

Hey you! Are you using git? I thought so. 

But how much is git helping in your daily coder's life? How much time do you spend identifying where a bug is? And how much time do you spend identifying why anyone introduced that bug in the first place.

Look no further, git bisect is here to help us.

I've found recently that git, if well used, can help us in more ways than just keeping track of changes for the sake of tracking them but to help us in our endless quest of fixing the bugs we coded a while back.

This git command has a simple concept. To find the commit that introduced a bug we must inform git about a bad and a good revision. After that, git, using a binary search algorithm, presents us with possible commits that may be good or bad, we, humans (for now, however, you can script this step, see https://git-scm.com/docs/git-bisect#_bisect_run), just tell it if this commit still has that bug or not.

With this algorithm, we are able to identify the origin of a bug for example in a range of 675 commits with just 10 steps.

Let’s see this in action.

The commands used in the following demonstration are:

git log # see commits
git log --pretty=format:"%h - %an, %ar : %s" # see commits displayed in a prettier and smaller way
git bisect bad # mark current version as bad
git checkout <revision> # go to prior commit
git bisect good # mark current version as good
git show <revision> # show changes on a specific revision
git bisect reset # resets current bisect session

In this demonstration, we have a file “index.html” with a bug that says that git bisect is a “bad” tool.

As we can see in the image above, that text doesn’t look right, someone changed a word from “good” to “bad”. One way we can approach this is just checking the git history for that line, but if we have many commits that’s slow and git bisect can rescue us.

We can first run a git log to see what we are dealing with.

git log --pretty=format:"%h - %an, %ar : %s"

In this case, we see that the author of the commits doesn’t even use helpful commit messages (so why are you even reading his stuff?).

We know for a fact that when we added the file the contents the word “bad” wasn’t there so let's check out that revision. 

git checkout 16d6ba6

So with this, we can start our investigation.

git bisect start # this will also checkout the head version (if we were in a detached head state)
git bisect bad # mark this as bad
git bisect good 16d6ba6 # mark this revision (or tag) as good

We can now see that in 3 steps we’ll find the first bad commit. So let’s get to it.

We can check out what changed in this commit easily with the git show command.

Don’t forget that you checked out a commit, if you are going to make changes, please use the git bisect reset command or git checkout before start working on a fix.

It doesn’t really matter the size of the project, or the number of files in it, as long as you can check out previous revisions and confirm that that revision is buggy or not easily, through the command line, your IDE, your browser or by compiling your application you should be able to use this to your advantage.

Fun fact: You can also skip a revision!

git bisect skip # in case you don’t want to test the suggested revision, you can skip it

That’s all for now, happy bisecting!

This is an article written by Pedro Caseiro, Software Engineer @md3

Pedro started out as a self-taught PHP and Javascript web developer. With about 6 years of professional experience, he's a fan of SPA. Recently he started to transition to back-end Python developments.