What Is GIT Bisect And How Does It Work?

Git offers a wide range of very useful tools for software development and it is very interesting to know and explore. Today I will talk about one of them: Git Bisect , ideal for when we want to look for something concrete in our code.

What is GIT Bisect and how does it work?

Bisect comes from binary search algorithm ( binary search algorithm ) and is an efficient way to search large groups of data (sorted). By dividing the stack in half repeatedly and applying some validation criteria we will be able to scan a large amount of information in a limited number of iterations.

We could make the bisect manually by simply checkout a commit specific and review the code, but the implementation that will provide protect us from possible mistakes and will save a lot of work.

When is a good time to apply bisect? When you are not sure when a specific change has taken place in the code; it can be a bug that you do not know at what moment it was introduced, or it is difficult to track, or an unwanted change, for example a piece of code that has been deleted by accident, etc. . . In all these cases, bisect can be very useful for you.

As an example let’s imagine that we have a bug. It is difficult to know what change caused it initially, but we are sure that a week ago it did not exist. Perfect, we can start the bisect.

Before starting with the bisect, please save all your work with a commit or stash !

First, we initialize the search with:

git bisect start

Then we need to mark two commits as good (good) and bad (bad) to specify the limits of the search. We will mark the current HEAD as bad, since the bug is currently playing:

git bisect bad

Then we must mark the time point in which we are sure that everything worked correctly. Same method, can be specified by the SHA, tag or branch of the commit, or simply by checking a specific commit and mark it as good:

git checkout 1234567

git bisect good

or

git bisect good 1234567

From this moment Git will begin to move the HEAD between commits offering us the possibility of verifying the status of the code at each moment. The instructions are quite explicit, and we can find something like:

Our task is to validate the code, either compiling and executing the application or launching a test case for the problem in question; everything will depend on this problem. Git will take us through the history of the code and will optimize step by step the number of validations that we need to do.

Our job will be to simply tell Git at what point the code was good or had already gone bad – “git bisect good” or “git bisect bad”. Git will automatically jump to the next candidate to be judged:

git bisect good

After the specified number of steps to be taken, Git will show us the suspicious commit and all its information.

In the end, do not forget to do a reset. In fact, do not be afraid to reset at any time in case something has gone wrong and you want to start over, such that:

git bisect reset

This is all you need to stop the algorithm elegantly.

In case you forgot to reset it well, Git stores all the necessary information in the .git catalog that you will find in the root of your repository. Removing all the `BISECT_` files from there will surely solve a good part of the possible problems related to bisect that you may encounter.

rm .git/BISECT_*

Time to recap Open a terminal, if you have not already done so, do `cd` to a git repository that you have around there and practice a bit.

First, check for pending changes and commit or stash them. Then, do the following:

git rev-list —max-parents=0 HEAD

This will give you the SHA of the initial commit of your repository.

You can start with “git bisect start” or pass the bad and good points (in this order). Try this:

git bisect start first_commits_sha_number_here HEAD

You should see an error message. It’s normal: you try to find a change from bad to good, that is, everything is fine and the command does not make sense.

The beginning of the bisect can accept one or two parameters: only the bad, or the bad and the good. With this in mind, let’s fix the command:

git bisect start HEAD first_commits_sha_number_here

The HEAD is bad. The first commit is good.

Now:

`git bisect good/bad`

You can also use `git bisect next` or` git bisect skip`. These instructions allow you to skip a commit in case it can not be validated.

Once you have finished, try:

git bisect log

to see it all again

git bisect run

to repeat the fun. Here it is interesting to mention that “run” can also accept a script to verify the code automatically.

Try also:

git bisect visualise

That will open your visual tool by default. Try experimenting with this while doing a bisect.

And the last trick of today (and for which probably should have started, but it would not have been half as fun for me). If you have not opened the terminal yet, this is your last chance – just do it:

git bisect

Here is a useful reminder:

usage: git bisect [help|start|bad|good|skip|next|reset|visualize|replay|log|run]

Summarizing:

Bisect is a simple to use search algorithm that allows us to scan quite long code histories in a reasonably short time and is also non-invasive. Just remember to start with your clean work directory and reset when you’re finished. Use it whenever you need to search your history.

The complete manual is available to you if you type: `git help bisect`.