You may have come across many articles about git, and most of them mention basic git commands. But git is itself a big FOSS which has a lot of hidden treasure inside it. This article will discuss a few more life-saver git features, which can save your efforts during the development phase.
So, this article will move around:
- git bisect
- 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 goodgit 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.
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.
You can find some more good-stuff at:
Git and Github: a Layman's Guide
If you are new to Git and Github, and even if you are not from any technical background, this article will clear all…
Git and Github: a Layman’s Guide[Part-2]
Hello peeps!! If you haven't read Part-1 of the series, then take a look over it for better understanding.
Git - git-blame Documentation
b Show blank SHA-1 for boundary commits. This can also be controlled via the blame.blankboundary config option. --root…