git Archives - CUTTING EDGE VISIONARIES

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

April 20, 2020April 20, 2020 by Hrishabh Sharmain Comps, YantrikaLeave a Comment

Reading Time: 5 minutes

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 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]

May 14, 2019May 14, 2019 by Hrishabh Sharmain Comps, GitLeave a Comment

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.

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.

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.

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.

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

git checkout new-feature

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.

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:

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/

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

May 10, 2019May 10, 2019 by Hrishabh Sharmain CompsLeave a Comment

Reading Time: 5 minutes

If you are new to Git and Github, and even if you are not from any technical background, this article will clear all your myths related to it.

Photo by Yancy Min on Unsplash

Git :

Git is just a software which tracks the changes in the files of your project.
It keeps the different versions of your files, hence it belongs to a category of software called Version Control System (VCS) so that different Versions of Software is in your Control
So if you are a developer, it can help you in handling situations like:

Reverting back to an older version of your code
Collaborate with the team effectively while working on the same project.

Repository :

The sole purpose of git is to track the changes in the project and collection of files and keep different versions of it.
So, the question is where does the git store these changes made in your project files. Here comes the concept of a repository, it is just a sub-directory in the root directory of your project you are working upon, which stores all the information related to changes in your files and much more useful information like who made the changes and when these were made.

Remote :

Suppose a situation where you are working on a team project consisting of different members. So the situation can’t be handled easily. A great hard-work will be required to merge the changes made by all into a single final project. And there can also be situations like there will be merge conflicts due to differences in a file which are stored on a single member’s machine. So we can say in this way, we can’t really collaborate on a team project.

Git solves this problem through ‘remote’.A git remote is a common repository residing on another central machine, which can be used by the whole team for collaboration on a team project.

Till now you know what is git, a repository and a remote. Another thing which we are going to discuss is “Github”.First of all, there is always confusion between Git and Github. Are they same thing or different?. So for more clarification-

— Git is a version control system, a tool to manage versions of your code
— GitHub is a hosting service for git repositories.

Now another question which can come into your mind is “How Git is gonna track and stage all the changes?”.The answer lies behind the distinct Git States, let’s tackle them first before proceeding-

Git States

The basic workflow of git includes the following three stages :

->Modified

It is the state when you make changes in a file, but it is untracked by the git.

->Staging

When you have modified a file or files, then you have to inform the git to look over and track the file if it is untracked till now, by taking a snapshot and this snapshot will go into the next commit. So we can say it is just the marking of a file to go into the next commit.

->Committed

It is the state when all the staged changes are stored in the local git repository or we can say the database.

After this much, we can continue creating a git repository on your local machine and then pointing it to Github. All you need is git installed on your system and a GitHub account.
We will be using Ubuntu for the tutorial but most of the commands are same for Windows also. Let’s Go!!

Step 1: Configuring Git

git --version

*To check the version of git and for making sure git is installed or not.

git config --global user.name "github username"
git config — global user.email “github email”

*Replace username and email with your GitHub username and email.

Step 2: Initialising a git repository

git init

Fire this command in your project directory and this will initialize a git repository and you will see a .git folder in your project directory.

Step 3: Connecting to a repository

a)Create a repository on GitHub for your project

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

b)Add a Remote

git remote add origin url

Replace url with the https link of your repository.

*In the above command origin is just a remote name, you can also use other names for your remote.

Hola!!All set up.

In case you want to use an existing project hosted on GitHub skip all the above steps and clone the GitHub repository in your preferred directory.

git clone url

Let’s move on to 4 more essential git commands-

git add filename

This command will add the file into the staging area.

*Replace filename with the name of the file you want to add into the staging area.
*To add all the files of the directory replace filename with .[dot]

git commit -m “commit_message”

This will commit all the changes which are currently in the staging area. So this command is a bridge between the staging area and committed area.

git push origin master

This command will push all the files of the local repository of the ‘master’ branch to the Github/Central repository with remote name ‘origin’.

*Ignore the word branch here. We will take a look at it later. So just use master in the above command.

git pull origin master

This will pull all the contents of the master branch stored on GitHub/Central Repository to your local repository.

Other useful commands-

git status

This shows the state of your working directory and helps you see all the files which are untracked by Git, staged or unstaged.

git log

It is used to check the history of commits.

Thanks for Reading!!

This blog was focused mainly on the basics of Git And GitHub. All the concepts like branching, merging, resolving merge conflicts will be covered in detail in Part-2. Stay Tuned 🙂

Keep Reading, Keep Learning.

TEAM CEV!!!