Find the commit that introduced an error in your code with Git Bisect

During WordCamp Europe 2019 I had the pleasure of attending the following lightning talk: Find that bug you made months ago with GitBisect by David Needham. Truth is, I found it very interesting and I thought it is worth briefly summarizing what I learned there, since it teaches how to save a lot of time when finding and correcting an error that you have inadvertently entered in your code.

You made a mistake months ago, and a part of the site is broken. No one noticed at first, but now the client is upset, so you need to fix it…and fast! But where in the code was this bug introduced? What if David told you there’s a tool hidden within Git to quickly find when a bug was committed and then fix it? Git Bisect allows you to comb through dozens of commits at once and find the culprit in seconds, even when you don’t know when it happened or what file was edited. Once you understand the basics, David will take it a step further with automation.

Summary of the talk on the WordCamp Europe 2019 website.

If you want to watch David’s talk, here you have the link:

How to (Shabbily) Find Where and When an Error Was Introduced

Imagine one of your users writes to you and tells you that they’ve encountered an error in your plugin. Damn! You know it has to be recent, as the issue they describe wasn’t there a few commits ago but… who’s the culprit? How do you find the exact commit in which the bug was introduced?

The simplest solution I can think of at first is to manually review your latest commits, one by one, so that you can find the exact moment where things go from “everything’s alright” to “here’s the bug!”

For instance, suppose your project has 100 commits and commit number 100 is what your client is using. The first thing you’ll probably want to do is reproduce the issue as described by your user, so you open your browser and give it a try. And, indeed, there it is! Then you go to commit 99 and repeat the process: you check whether the bug is also in commit 99 and, if it is, move to the next step. Commits 98, 97… you repeat the process over and over again until you reach a certain commit (73, for example), where everything works correctly. Where was the problem introduced? Exactly: commit 74.

It took you 100-73 = 27 attempts to find the faulty commit ? but, hey, at leats you now know where the error appeared and you have full access to the changelog, so working in the solution should be straightforward. ?

Nelio A/B Testing

I was very impressed by the quality of this plugin, how easy it was to set up, and the outstanding support Nelio provides. I highly recommend Nelio A/B Testing.

Josette Millar

WordPress.org

View Plans

How to Find the Error Quickly and Effectively with Git Bisect

Now forget about the previous shabby solution and let’s use the method that David Needham explained in the WordCamp Europe 2019. We have an error in the most recent commit of the project and we want to find where that error was introduced… what do we do?

Well, the first thing is tell Git we want to bisect our code to find a culprit. To do this, simply enter the following command in the folder of our project:

git <span id="urn:enhancement-583b34a9-5fb7-c925-7d7b-cca4f84f959f" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Bisects_and_splits"><span id="urn:enhancement-e6bf22c8-796a-0083-e6cd-0e745e22ad45" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Bisects_and_splits">bisect</span></span> <span id="urn:enhancement-657a9101-7bd1-b23c-9595-1b0e1c450bc8" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Starting_lineup"><span id="urn:enhancement-7c7d8c91-4e8c-2953-8e53-8fa83094cb4a" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Starting_lineup">start</span></span>

Assuming we’re in HEAD, and given the fact that we know this commit fails (we reproduced the issue, remember?), let’s simply tell Git that the current commit is wrong:

git <span id="urn:enhancement-0331788b-fcd7-4503-87a0-1335d2d939f0" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Bisects_and_splits"><span id="urn:enhancement-e2f754aa-7b7b-a545-9abe-1aa92ad74fab" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Bisects_and_splits">bisect</span></span> bad

Next we have to tell Git about one previous commit that we know (or think) is correct. For instance, let’s assume that we know the first commit of our project is correct (hash c1fd602276). Let’s tell Git so:

git <span id="urn:enhancement-0e2a7c8d-2b7f-f419-a5d1-807ac06c821d" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Bisects_and_splits"><span id="urn:enhancement-7f25c957-6002-e0f2-91f1-353e2077f7ce" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Bisects_and_splits">bisect</span></span> good c1fd602276

As a result of this command, Git will tell you the number of commits between your last valid commit and the faulty one, as well as how many steps it’ll take to find the culprit:

Bisecting: 98 revisions left to test after this (roughly 6 <span id="urn:enhancement-d11d0b19-ee31-912d-0b8f-39bfa4ca5fa6" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Dance_move"><span id="urn:enhancement-b98b9fbd-1e0e-c32b-61b4-9759e6dd5f9b" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Dance_move">steps</span></span>)

as well as automatically selecting a commit between the two. In our example, Git has automatically selected commit 50 and is waiting for us to tell it whether this commit is right or wrong. Let’s assume it’s fine:

git <span id="urn:enhancement-2c578b91-3420-169d-04eb-494fe06babd9" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Bisects_and_splits"><span id="urn:enhancement-680f2625-403e-a4c4-48a5-793d8b6eac8e" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Bisects_and_splits">bisect</span></span> good

Since commit 1 was OK, and so is commit 50, Git assumes that commits 1 to 50 are also OK and therefore the issue must lie between 50 and 100 (HEAD). Then, Git looks for the commit that sits in the middle of commits 50 and HEAD (namely, 75) and, again, asks us “what about this one?” We check commit 75 and we see it’s not working, so we let it know:

git <span id="urn:enhancement-7644c892-ba43-40bf-4522-1401a1dcac46" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Bisects_and_splits"><span id="urn:enhancement-420615c4-8db0-feac-6879-8940771f480b" class="textannotation wl-thing" itemid="http://dbpedia.org/resource/Bisects_and_splits">bisect</span></span> bad

and now Git knows that commits 75 to HEAD are wrong, so the culprit has to be between 50 and 75. Git Bisect repeats this process over and over, discarding half of the commits each time, until 6 steps we find the culprit in about 6 steps.

Pretty cool, huh? The possibilities offered by Git are amazing. It’s unbelievable how much time you can save if you know your tools a little better. I strongly recommend that do not miss David Needham’s talk (linked in this post), because he discovers a few more tricks I haven’t covered in this (short) post. I’m sure you’ll love them!

Featured Image by Kay on Unsplash.