Let's Know About Git Branches 📥📤 And How To Implement It

Introduction

In my previous article, we discussed about empty repository with setup details and steps to initialize a git repository. We have also discussed how to push the changes to the GitHub empty repository and add multiple files to the staging area using a single command.

In this article, I will describe the below-mentioned points in detail.

Know about the git branch
Steps to create branches in GitHub
Why the use of git branches
Git branching real-time strategy
DevOps Importance In Agile Methodology
UsingBranching strategy to solve deployment issue

Note. Before going through this session, please visit my below-mentioned session related to Git and GitHub.

What Is Git Branch?

Git branch is nothing but a copy of the source code. The source code is when the application is written using backend code like Java, .NET, etc and for the user interface, the code is written using HTML, CSS, jQuery, Angular, and Bootstrap. Also, database-related scripts using SQL Server, Oracle DB script, MySQL, etc. So, the Git branch is the container of all these things. So, that way a developer can easily find the source code, by whom it was written, and using what language and it can be tracked easily. See the below diagram.

Branch

Here the left side symbol identifies the git branch. In the git branch, there is one default branch which is auto-created during the creation of a new repository, and another option for creating a new branch as shown in the diagram.

Default Git Branch

New Git Branch

Git Branch with an example

As per the above image, I already have a default branch called main with committed files but I want a set of copies of those files. To understand better I describe it with the below Git Branch diagram.

Git Branch

Here I have one GitHub repo and in this repo, I have 3 branches Master, Testing, and Production. Here two developers, DEV ONE and DEV TWO, are connected to the default branch called the Master branch. So, whatever files they commit and push, those changes will be pushed to the Master branch only.

Let's take an example as these 2 developers are working on a common project called an online food delivery site. So, they finished the user registration page and pushed the coding part to the Master branch inside that GitHub repo as shown in the diagram. Once they commit their code to the Master branch, we are going to take this code and deploy that code to one of the application servers called the Dev Application Server. Once deployed then these developers connect to the Dev application server and test their code to see whether code works fine or not.

Now, whatever set of code is deployed in Dev Application Server, that same set of code will be deployed in the Testing Application Server because the developers are doing a round of testing called Sanity testing by sanity integration using RedisInsight. So, as per earlier discussion once the same code is deployed in the Testing Application Server or you can call it a Quality Assurance (QA server) then testers will test the application thoroughly with positive and negative test cases.

DevOps importance in Agile methodology

Here what Agile says is instead of developing an entire application and releasing it after 6 months and 1 year, we have to release the application feature by feature. As per earlier discussion on the food delivery site, first, we release the user registration page then release the sign-in page. After that, we add some modules to that food delivery site. Next, we add the options called add to cart and payments. Using the same process they are going to release feature by feature. So, as per earlier discussions, our first release for the user registration page is pushed to the Master branch, and these codes are deployed to the Dev Application Server and then deployed to the Testing Application Server or QA Server. Finally, we move the code to Production Application Server where our end user will be using our application.

So, as per Agile methodology once one functionality is completed and it's deployed to the Testing Application Server and testers are started testing these implementations of code it takes 3 days. For these 3 days, the developers will not sit idle. So, they have to start working on the next functionality called sign-In page. After that, they move the code to the Master branch. As per the DevOps automation flow, the developers will take the code from the Master branch and they will deploy it in Testing Application Server. So, what happens is the testers will not get the stable code because the Sign-In functionality is available in the Testing Application Server. The user registration page functionality is not working here that is the Testing Application Server. So, what developers deployed the new Sign-In functionality because of that tester will face issues.

The solution to the above issue using a Branching Strategy

Here I will maintain a separate copy of the code. Let's explain this scenario using Branchingstrategy. First, these developers complete a user registration page functionality. Then these developers will push the code to the Master branch and deploy it to the Dev Application Server. Once the sanity testing is done by developers thoroughly, next, instead of deploying the code to the Testing Application server, these developers will move the copy of the code from the Master branch to the Testing branch. Here the code will be deployed from the Testing branch to the Testing Application Server and the testers will start testing the code for User Registration functionality. The developers will not start idle and they start implementing the functionality of the Sign-In page and push the code to the Master branch. Next, these developers started sanity testing in the Dev Application Server. After that developers will push the code to the Testing branch. Here in the Testing branch bothUser Registration and Sign-In functionality will be available and both functionality codes will be deployed from the Testing branch to the Testing Application Server. Finally, the testers can test this functionality without any issues because there is no dependency or relation between these copies of codes in the Master and Testing branches.

Next, these developers will start working on the next functionality called the payment option. After these changes, the developers will push the code to the master branch, and after sanity testing is done, these changes will move to Testing branch and then deploy to the Testing Application Server. If the testers will find any defects then these defects will be assigned or informed to developers to fix that issue. After that defect is fixed the developers will push the code Master branch and then move the same copy to the Testing branch. Now once we have tested that functionality in the Testing Application Server and if everything is working fine then we will move the copy from the Testing branch to the Production branch as shown in the above diagram. Now we deploy the code from the Production branch to the Production Application Server. Like this, we need different copies of branches. This one is the best example for understanding branching strategy in real-time scenarios. Here we can create a number of branches and also we can use any branch for any environment i.e. Development, Testing, or Production. There are no restrictions at all.

Understanding the uses of Branches for the Environment in the Real-time world

In Real-Time scenarios, there are various environments as shown below.

Development: It can be used for Development. Developers will use this server.
Testing / QA: It can be used for testing or for QA purposes. Here QA can be split into QA1, QA2 .... QA6 as per requirements. Testing or QA people will use this server.
Preprod: Before go for production or live server, This environment will be used. Mostly QA people or senior people of this specific project will use.
Production: This can be used for end-user or client purposes. The client can use this server. This is the final server and it reaches to end user or client.

Here, I show you the branch is used for the environment as shown below.

Development branch: For Development environment.
Testing branch: For Testing environment.
Preprod branch: For Preprodenvironment.
Master branch: For Production environment.

There is no mandatory rule that for environment we create n number of branches. That is based on the decision of our Organization. It can be less than that or more than that.

Steps to Create and Manage New Branch

As per the previous article, I created a repository called SatyaTwo and it comes under a branch called mainas shown below.

Manage New Branch

Here I will create a branch called Testing as shown below.

Testing

Here I type the name of the branch called Testing and below you can see a line that shows Create branch: Testing from 'main'. That means when we create a new branch that should not be empty. We have to create this new branch from some other existing branches. Here my branch is the main branch That means whatever changes are present in my main branch will be copied to this Testing branch. The testing branch can have the same copy of files as there in main branch.

Here you can see your new branch is created as shown below.

New branch

Here we can see the same no. of commits and no. of files are shown in the Testing branch as there in the main branch as shown below. Here we can see the new branch with the selected option.

Selected option

Here we can see the same no. of files with commit messages as shown below.

Same no. of files

Here we check one scenario that whatever changes are made in the main branch will not affect the Testing branch. Let me explain with an example.

Here I select the main branch and select MyFile.cs file for modification as shown below.

Main branch

Here I modified the MyFile.cs with the below lines.

Modified

After Commit changes the file MyFile.cs will be shown as mentioned below.

Commit changes

If I go to the SatyaTwo repo for the main branch and check the no. of commits is 6. The MyFile.cs with new commit message as modified in the main branch. The committed time is shown below.

MyFile.cs

Let's check the same file called MyFile.cs status i.e. no. of commits, commit message of MyFile.cs, Committed time under the Testing branch as shown below.

Testing branch

Here we got that the change was made in a file called MyFile.cs under the main branch. That change does not affect the same file MyFile.cs under the Testing branch.

Let's check also the content of my file.cs under the Testing branch. The new content added in MyFile.cs under the main branch is not affected in the same file under the Testing branch.

Content

Like this, you can maintain this separate copy of source code using branches.

Maintain separate copies of source code using the New Branch and Testing Branch

Here I created a new branch called Preprod from the Testing branch instead of the main branch. So, for this, we need to select the Testing branch and then create a new branch called Preprod as shown below.

Preprod

Here after the successful creation of the Preprod branch, We can see the same no. of commits, files with commit messages, and committed time as same under the Testing branch.

Preprod branch

Here you can see the total no. of branches that are created in the SatyaTwo repository as shown below.

SatyaTwo repository

Summary

In this write-up, we have learned the below details.

Know about the git branch
Steps to create branches in GitHub
Why the use of git branches.?
Git branching real-time strategy
DevOps Importance In Agile Methodology
Using a Branching strategy to solve deployment issue

Thank You & Stay Tuned For More