Getting Familiar with Some Cool Git Commands- git bisect & git blame

Getting Familiar with Some Cool Git Commands- git bisect & git blame git
Reading Time: 5 minutes

So, this article will move around:

  1. git bisect
  2. git blame

So let’s discuss them one by one, with the situations in which they can be used.

Finding Regression Error using ‘git bisect’:

‘git bisect’ will work as a life-saver spell if you need to find a regression bug introduced in your software accidentally. Such type of errors are common in group projects or open-source, in which some contributor unintentionally changes certain important piece of code, which breaks some other functionality, and it remains unnoticed for a long period of time. So, when such bug comes under notice, the main task of the maintainer is to track when this bug/breakage is introduced or to say before which commit, all things were working correctly.

So, the general approach to this problem would be to find a commit at which things were working correctly, and perform a binary search between the good commit and the latest commit to find the commit at which things were broken. This will narrow down the consideration window with few rounds of compiling.

Of course, it is a perfect approach, but doing it manually and keeping an eye on the good and bad commit makes the process cumbersome. So here comes the ‘git bisect’ for rescue.

To find the bug, firstly checkout to master and handover the git the responsibility to find the regression bug by firing:

git bisect start

By the above command, before the git starts the process you need to give a reference to a bad-commit and a good commit.

Assuming things are bad at the current HEAD, for giving reference to a bad commit use:

git bisect bad HEAD

After that, to perform a binary search, a reference to a commit, where things were working as expected, is needed. So, just take the hash of good-commit and use:

git bisect good <git-hash>

After this stage, git will start the process to find the breakage point. It will automatically checkout to the intermediate commits. All you need to do is to mark the checked-out commit as good or bad by:

git bisect good
git bisect bad

 

Let’s see this with example. Consider the file:

In this file, at line-4 the correct word was ‘Blockchain’, but accidentally it has been changed. So let’s find out the commit, before which everything was good.

Here is the git-log for reference:

Let’s start the git bisect and as things were good at ‘add Blockchain’ commit. So let’s take it as a good commit and take the latest commit as bad commit.

You can see that git take over the task of divide and conquer, and also displays the rough steps remaining in finding the regression point. So, all you have to do now is to mark the current checked out commit as good or bad.

After seeing the file at ‘add compiler design’ commit, we can conclude it as a good commit, as the spelling is correct there. So, let’s mark it as good commit.

The next bisect point is a bad commit, so let’s mark it.

Again, it’s a bad commit.

Whoops, we just found the commit at which things the word was misspelt. It is the commit with the message ‘add MP’.

In the same way, you can find regression bugs very easily in big projects :).

It saved me many hours, so will also save yours.


Finding the culprit for breaking the code by ‘git blame’:

The official documentation says, git blame-

Annotates each line in the given file with information from the revision which last modified the line. Optionally, start annotating from the given revision.

So in short, it is used to find the person in a group project, who changed the line and responsible for breaking the project.

So, git blame command will give you the information about the latest commit that changed the line, for all the lines accompanied by the author of the commit.

Command:

So let’s try this out by :

git blame <path-to-file>

Clearly, you can see the latest commit hash which changed the Line-4. Although the author in these commits are same. But if it is a team project, you can also judge which person broke the code, so that you can blame him, to have a coffee :).

You can also use GitHub to find the git blame for a line:

 

Similarly, GitLab also has the option to view blames:

That’s all for this article and Don’t forget to ‘Clap’, if you have found it useful.

References:

https://git-scm.com/docs/git-blame

https://git-scm.com/docs/git-bisect

You can find some more good-stuff at:

GIT and GITHUB: A Layman’s Guide[Part-1]

GIT and GITHUB: A Layman’s Guide [Part-2]

Leave a Reply

CEV - Handout
%d bloggers like this: