Git for Professional Part-1

Almost every Software developer uses git. Many use it constantly throughout the day. While some may already know the very basics of git, productivity will be increased if you learn a few advanced git concepts, which we will discuss here today.

So let's talk a bit about how to create the perfect commit.So the first part is to add the right changes, right. And the second part is to compose a good commit message.

So let’s talk about the first part of a perfect commit which is to add the right changes. So the Git staging area concept is really helpful in this context, it allows you to select specific files, or even parts of those files for the next commit. So this is what the staging area can do for you, you can really select individual files for one, commit, and even parts of files for one commit and leave others for future commit.

Let’s take an example, suppose we have changed a lot of files. But let's say that not all of those are about the same topic. So let's stick to that golden rule of version control to only combine changes from the same topic in a single commit.crafting a commit like this in a very granular way, will help you create a very valuable commit history, one that is easy to read and to understand. And this is crucial if you want to stay on top of things.

Now let's talk about the second part of creating that perfect commit. And that is providing a great commit message.

Commit message is very important in terms of understanding code changes in future or for another developer who is working in a team. Generally, the advice is to write something very concise, less than 80 characters if possible.

So here are a couple of questions you might want to answer with your commit message body this year: what's now different than before, what's the reason for the change? And is there anything to watch out for or anything particularly remarkable about that commit.

For instance, we have added a feature for sending mail so the commit message will be concise like “Added mailing feature for —” and this will help other team members to understand what feature has been added in this commit.

Let’s talk about branching.

Now let's look closer at two main types of branches and how they are used. These two types of branches are long running and short lived branches.

So let's start by talking about the long running branches first.

Every Git repository contains at least one long running branch typically something called main or master. But there may also be other long running branches in your project, something like development or production or staging, which are called integration branches.Typically, these branches represent states in a project release or deployment process.?

Commits should only make it to the long running branch through integration. In other words, through a merge or rebase. There are a couple of reasons for such a rule. One has to do with quality. You don't want to add untested and reviewed code to your production environment as an example. And that's why code should go through different state tests and reviews before it finally arrives on production.

Now the other type of branches are short lived branches.

These short lived branches are created for some specific purpose and are deleted after that purpose.And typically a short lived branch will be based on a long running branch.

For example, when you start a new feature, you might base that new feature on your long running main branch for example, and after making some commits and finishing your work, you probably want to re-integrate it back into main. And after you've safely merged or rebased it your feature branch can be deleted.

I think this is enough for this week’s article. I will discuss more about pull requests, merging strategies in next week’s article. Stay tuned for more amazing content.