You don’t know what it is? Let me tell you about this! It’s a helpful tool gifted by the git.

The idea behind git bisect is to perform a binary search in history to find a particular regression. This is very useful for debugging your previous commit.

Problem:

The tedious way of finding a bad git commit is something we’ve all done before. You checkout some old commit, make sure the broken code isn’t there, then checkout a slightly newer commit, check again, and repeat over and over until you find the bugged commit. If there is a large number of commits, this can take a long time.

Answer:

Let me start execution.

Start with running the git bisect start a command start to bisect session. Then run git bisect bad to tell the bisect session that the current commit is a bad commit. then, run git bisect good <sha-of-good-commit>. <sha-of-good-commit> the commit should be the one until which your test case was getting passed. The response will look something like the following:

This means that there are 41 commits left that can contain the commit you are looking for and that it will take about 5 more steps to find it.

Now run your test suite. If the test case gets passed then we need to run git bisect good, otherwise git bisect bad .

After having specified if the commit is either good or bad bisect will respond with a similar message:

Now binary search magic comes, In this step it has eliminated 31 commits, and there are only 10 commits left that can contain the commit you are looking for.

Keep repeating this process until it reports the bad commit and then runs git bisect reset to get back to the HEAD commit.

Bisect Automate:

Voilà! the long and unexciting task of finding buggy code is done in only few minutes!
If you like the content, please clap 👏👏👏