Git Bisect: A Love Story

This is a guest post contributed by Raphael Eidus. Read on to find out more about Git Bisect, the tool (if you’re not familiar with it) you always wished you had to find those tricky bugs.

Earlier this week I was working on portion of a mobile web app, adding a new feature with a coworker. We, being good code citizens, were working out of a feature branch so as to not corrupt master and everything was going well. The feature was coming along and it was ready to head to staging. But on staging I noticed something strange. One page kept re-rendering, infinitely flashing off the screen, and making itself unusable. What was even more confusing is that our feature didn’t touch this page. I had no clue what had happened and no leads.

In Steps Git Bisect

Git Bisect is a tool for finding the commit that introduced the bug. The first thing I did was checkout the commit where I branched off master. This was to verify that the bug was not present in that commit, and it wasn’t.

This is good news. I have a point that I know didn’t have the bug, and I know that my current commit has the bug. So now I need to search for the commit somewhere between these two end points that introduced the bug.

My branch point (no bug present) has a hash of 87ab7d60. And I begin the Git Bisect process:

git bisect start

git bisect good 87ab7d60 # where I branched from master

git bisect bad

Git Bisect takes over from here and checks out the commit between the two endpoints. I then test it for the presence of the bug. Not there. Next:

git bisect good

With this command, the next commit in the tree is checked out, and there are 82 more commits to check (about 7 steps). At this point, I check for the bug in the browser, and it isn’t present, so onward with another git bisect good.

Git Bisect checks out the next commit; I check again this time the bug is present. This calls for git bisect bad. I repeat a few more times, until finally we arrive at the first commit that introduced the bug. A simple git show displays the diff of what changed.

If you ever arrive at a commit that wont build for a known or irrelevant reason, run git bisect skip. It doesn’t define it as good or bad and moves on.

Looking through the diff, I see mostly CSS changes but none of the JS changes that I thought would be the cause of this bug. This was interesting:

- <div id="header">
+ <div class="header">

This couldn’t possibly be the cause of bug, could it?

So I move back to the HEAD (git bisect reset) and change the line to <div id='header class=‘header’> and refreshed the browser … and suddenly the bug was gone.

This bug manifested itself in a really weird way that was extremely difficult to track down, but bisect allowed me to find the exact cause in about 2 minutes. I would have spent hours, if not days, trying to figure out what the hell this was, and would have become extremely frustrated.

Bisect saved me hours of work and stress. Bisect isn’t something that I need often but when I do, I am oh so happy to have it.

For more info on git bisect check out the documentation here (it’s actually fantastic): http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

Tags: , , ,

4 Responses to “Git Bisect: A Love Story”

  1. Jason December 13, 2012 at 12:24 pm #

    Very informative post. Unlike most I’ve seen recently this actually provided me with an example whilst still being relatively brief and readable.

  2. Rob Baltzer December 17, 2012 at 7:23 pm #

    Thanks for the concise refresher on bisecting. This functionality has saved my bacon several times in the past.

  3. Myles McDonnell December 18, 2012 at 11:18 am #

    Good post, thanks. I can envisage automating this process on a CI build, running only the failing tests to find the bad commit fast.

Trackbacks/Pingbacks

  1. Colin’s Weekly Roundup – Week Two | Gallery.Clipapic - December 21, 2012

    […] Git bisect: a love story (use Git to identify which change introduced a bug) […]

Leave a Reply