Have you ever encountered a bug and don’t know what caused it? Don’t want to sift though hundreds of commits to track it down? Pulling your hair out because it feels hopeless? Feeling like Kanye West on Sway?

Git Bisect is the answer! Today I’m going to show you the power of Git Bisect and how it can quickly find the EXACT commit where your bug happened.

What is Git Bisect?

Git Bisect is a command line tool built into git that allows you to use binary search to find buggy commits.   Binary search makes finding things exponentially faster, instead of looking at commits one by one, you would divide your list of commits into two equal parts, you then look at each part and see which part contains the bug, you then continue on this process until you arrive at a single commit.

Demo Time!

I always believe the best way to learn is to demonstrate.  First you need to grab the code from my Github repo here: https://github.com/yongzhihuang/PentaCode , navigate to gitBisect subfolder and you should see the project files.  Open index.html in your browser and you should see a simple bootstrap site

When everything is working, when clicking on the Make Something Happen button, the site is suppose to slide up the jumbotron and show another jumbotron.  However, when we clicked on it, nothing happens, but this was definitely working at some point!

So let’s start our search for the bad commit(For demonstration purposes our commit list is about 10 or so, but in the real world, it can be hundreds or thousands!):

git bisect start

this starts the git bisect process, on our current commit, the bug is present, so we need to designate it as a bad commit

git bisect bad

next we need to find a point in time when the bug was no longer present, we need to get the commit SHA from git.  You can accomplish this in two ways, either with git log or by going to Github and look at list of commits, we’ll be doing the latter method. Looking at our git history, let’s checkout the commit with the message “works” and see if our code is working:

git checkout 6d20e542a1b99e98eccdc7a240986905c17e9a8c

Now refresh our index.html page and click on the “Make Something Happen” button…YAY it worked!  So this means this commit has no bug, so we’ll need to designate it as good

git bisect good

you’ll see git sending you the following message back:

Bisecting: 3 revisions left to test after this (roughly 2 steps)
[dded55772d4adc3c13aebb7db4fe2785d2b7d87e] Open yt channel in new link

git bisect automatically switches your code to the next commit in list that it thinks contains the buggy commit.  All you have to do is to refresh index.html and see if the bug is still there, if it is, then type git bisect good , other wise type git bisect bad

and with a bit of Q&A we were able to arrive at this exact commit:

~/Desktop/Development/pentacode ((bd75420...)|BISECTING) > git bisect bad
bd75420d1f7c36d3a0adafef6108705148414db1 is the first bad commit
commit bd75420d1f7c36d3a0adafef6108705148414db1
Author: Yongzhi Huang <yongzhihuang@yahoo.com>
Date:   Tue Aug 30 08:33:02 2016 -0400

    hmm this is a weird commit

:040000 040000 1e87f3320ac61f5768b42bca315719c02e685c29 db93f8b9d6d17634aa8d8b317442496502380074 M	gitBisect
~/Desktop/Development/pentacode ((bd75420...)|BISECTING) > 

We found our bad commit, it’s time to exit the bisect tool:

git bisect reset

Pretty amazing isn’t it? Git Bisect shines even more when you have hundreds or thousands of commits to sift through!

I hope you find this trick useful, hopefully you will impress your colleagues with your new debugging ability!