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

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]

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

Reading Time: 5 minutes

Hello peeps!!
If you haven’t read Part-1 of the series, then take a look over it for better understanding.

In the Part-1, most of the jargons related to Git and Github and basic commands have already been discussed. Still, there is much more to learn like how to revert back the changes, what is branching, merging, etc.

 

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

Giphy GIFs

 

So hold your coffee and let’s begin & try to understand them one by one in simplest form and don’t worry we are not going to deal with any PPT, Lol!!

We have used the term master branch in the previous article several times.
So Let’s discuss it first..

Branching :

We will try to relate this with a real-life scenario at first and then we will move on to the technical explanation.
Imagine you are working on a team project. In such a project, there are often bugs to be fixed and sometimes a new feature has to be added. In a small project, it is easy to work directly on the main version, technically ‘master branch’ but in case of big projects, if you do so there is a high probability that you and other teammates may make changes which are conflicting. So the solution for this is ‘branching’ in git.

For proper understanding, you can think of the main git chain as a tree trunk which is technically called ‘master branch’.So whenever you want to work on a new feature, you can make a separate branch from the main tree trunk or master branch and start committing changes in your new branch and once you think that your feature is ready you can again merge that branch in the master branch.

Let’s understand this in a more robust way and also discuss the basic commands related to branching.

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

Branch in git is a special pointer to one of the commit. Every time you make a commit, it moves forward to the latest commit.

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

Another important point to mention is that git has a special pointer called
HEAD to keep track of the branch you are currently working on.

Let’s create a new branch with the name ‘new-feature’.

git branch new-feature

This will create a new branch(a pointer) on the same commit you were working on.

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

 

Note that HEAD is still on the master branch. You need to checkout to switch to the new branch.

 

git checkout new-feature

 

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

 

NOTE-You can create a new branch and immediately checkout to the new branch by:

git checkout -b new-feature

Let’s start working on the new feature and make a new commit.

 

 

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

 

Now if we check out to the main branch again and make a new commit, the new-feature branch will not be affected at all. Let’s do this:

git checkout master

After some changes, and commiting the new changes:

 

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

 

So, you can see how you can work on a new-feature without disturbing the master branch and once you complete your task on the new-feature you can “merge” that branch into the main branch.
Isn’t it amazing that you and your team can work on different features by creating multiple branches and later  merging them into master? Hell Yeah!!!

Now Let’s discuss a little bit about merging and basic commands related to it.

Merging :

Whenever you make a separate branch for working on a feature, you can commit your changes in that branch. But when you task related to the feature for which you make a branch completes, you need to merge that branch into the main codebase/master branch and this process is called ‘Merging’.

Suppose your task on a new-feature branch is now complete and you want to merge that branch into the master branch. Then firstly checkout to the master branch.

git checkout master

And use the following command:

git merge branchname

*Here in our case branch name is new-feature.

 

This command merge the changes you made in new-feature branch with the master branch by squashing them into a new commit that has information related to the two parent commits.See the picture…

 

GIT and GITHUB: A Layman’s Guide [Part-2]
And here comes the bad part….
Source:pando.com

Merge Conflicts :

When you merge a branch with the master branch, then there are chances you run into
‘Merge -conflicts’.
Basically, ‘merge-conflicts’ arise when you changed the line of code that someone
else also changed.

In such a situation, you manually have to decide which version of the code you want to keep that is you need to resolve the merge conflicts.

That’s All!!! Thanks for reading the article.
The next blog in the series will focus more on using GitHub.
Stay Tuned.

Happy Learning 🙂

TEAM CEV

References: https://git-scm.com/

CEV - Handout