Git Bisect

Debugging with Git Bisect

Today I’m going to write about Git Bisect. This is a very useful tool to find any specific error in our code.

What is Git Bisect?

Bisect means binary search algorithm and is an efficient way to search large groups of ordered data. It divides the data in half several times and applies a validation criterion. Thus, we can scan a large amount of information with few iterations.

When is a good moment to use bisect? When you want to search for a change and you don’t know when this change happened. For example, you have a version 2 and you have an error or you have accidentally deleted some code, but you know that on version 1 everything is working. But between version 1 and version 2 you have 15 commits and you don’t know which commit caused the error.

How to work with bisect

To start you have to know the last commit where everything was working well and a commit where everything broke to specify search limits.

To start we put:

git bisect start

Then you have to check the last commit where the bug doesn’t exist. You can add the commit SHA, tag or branch and put it “good”:

git bisect good 123456789

And now, you have to add the commit where you know that the bug exist:

git bisect bad 987654321

Now, git starts a binary search: it splits commits in half and shows you the commit in the middle and you have to tell if this commit is good or bad. For instance, we have 15 commits between our v1 and v2, so you will see a message like that:

Bisecting: 15 revisions left to test after this (roughly 4 steps)

And bisect puts you on the seventh commit. Now you have to run code and check if in this commit everything is working or not and tell bisect your answer:

git bisect good||bad

Then, bisect jumps into other commit to test other and you have to repeat the test and put the answer:

git bisect good||bad

And so on until finding the commit where your code does not work.

If you can’t test a determined commit, you can run git bisect skip and jump into the next commit.

When bisect finds the first bad commit it gives you this answer:

135792468 is the first bad commit

And here you have your problematic commit! If you make: git show 135792468 you will see the changes done in this first bad commit and fix it.

To end with bisect you only have to run:

git bisect reset

And et voilà! thanks to this, we have been able to test 15 commits in just 4 steps. It saves you from testing all commits one by one. It’s so quick and very useful.

But that is not all! You can automate some tests with scripts. You only have to run:

git bisect run [script] [arguments]

For instance, you have an error while compiling your code. You can automate bisect to find the first bad commit like this (think that my script to compile my code is npm run build-prod) and find where the compilation stopped working:

git bisect start
git bisect good 123456789
git bisect bad 987654321
git bisect run npm run build-prod

If you have an error 0 is that this commit is good. If you have a 125 error means that bisect can’t do the test and jump into the next commit (like git bisect skip). Any other error means that the commit is bad.