Git Down, Git Down


Been a while since I posted something, but thought I might share a little bit of information that has been useful recently. As some of you are aware, I’m working as an engineer for a big educational company who are launching a new online courseware in the next few weeks. As a result, there is a lof of QA testing going on and a lot of bugs to be fixed. Sometimes, it’s a bit tricky to track down where a bug has been introduced, but after a chat with Mikael Karon (the guy who created TroopJS, which is an awesome little framework for creating widgets and connecting stuff together) I was introduced to a function known as git bisect.

This little beauty has helped me trace down two niggling little bugs that would have otherwise taken me hours to track down in the code. So, how does it work? It’s super simple. There are just a few commands you need to know:

git bisect start
git bisect bad
git bisect good
git bisect reset

First of all, make sure you are working on the right branch/fork or however you use your git for source control and in your commandline of choice (Git Bash, Windows Command Prompt, Powershell, Unix Shell etc…) naviate to your local repository and run:

git bisect start

It seems that nothing has happened, but what is really happening is git is waiting for you to tell it where there is a good version and a bad version. For this, you kind of need to know roughly where it was working last. But we’ll come to that bit later.

Firstly, chances are you’re at the point where the feature/code is not working properly. If that’s the case, just go ahead and tell bisect that it’s bad with one of these:

git bisect bad

Again, it looks like nothing has happened, but fear not! You just need to tell it where the code was good. To do this you need to know the hash of the commit where it was working before. As with most things in Git, you don’t need the full hash… Just the first 8 or so characters will do. For example:

git bisect good a6bc9ac1

Obviously replace ‘a6bc9ac1’ with your own hash… :-/

Now we get some response from git! It should tell us how many commits there were between good and bad, and approximately how many steps it’s going to take to get to the cause (hopefully).

It has also rolled the code back to a point in between the two commits. So all you have to do now, is test that code for the bug… When you finish that, you’re either going to find the bug is still there, or it’s not.

If it’s still there, tell git that it’s still not fixed with:
git bisect bad

If it’s vanished! Let git know this was a good commit with a:
git bisect good

Eventually, you’ll get to a point where git narrows it to a single commit where the code was changed. Your repo will now be at that point, so you can have a look at which code changed in that commit. If there was a large amount of code that changed, it’s a bit of bad luck, but at least you know that this is where it broke. Once you pinpoint the code which is causing the bug, you need to get out of bisect mode to correct it in the HEAD. To get back there you just need to do:

git bisect reset

You’ll now be back at the head of your branch/fork and ready to implement the fix for that bug! You could also see who broke it, but instead of playing the blame game, just get the code working and keep everyone happy. 😉

Until the next time: Catch you later!