This article is in continuation of one of my discussions on LinkedIn where we will talk about Git Branching Strategy for QA.
LinkedIn Discussion :
Hello Lakshay …
Hope you are doing good. I just have one quick question.
For an automation project which of the following is the best practice for git branching?
- Create a separate branch for each n every QA and then merge them to master?
- To have only 2 branches for the entire project ? 1 as working branch n other as a master?
The first thing is to consider is that code should be treated as code, and it should follow the same rule as any development team follows.
I looked at almost every reply in the discussion. There are a few which makes sense and few where I see that I need to shed some light. My solution is the mixture of my views and a few great suggestions I got in comments. Here is one approach that I think will be efficient and I would follow in my project. However, please mind that there could be other approaches that may be better.
Before starting with the explanation, I request you guys to follow TOOLSQA for all the important discussions, post, market trends, and jobs.
Git Branching Strategy for QA Automation
Let’s understand this scenario with the help of an example, and here I take the opportunity to introduce #Agile & #Sprint as well. Let us say, there is a working product/website which has done a few releases in the past. A new release, let’s say Release-5, is in development and there are few sprints planned for it. The test team is supposed to deliver automated tests for every feature build in the Sprints. There can be multiple features in the Sprint as well, depends on its size. For this discussion, assuming there are.
I prefer using Master, Develop & Feature branches, so I will explain the above scenario according to this approach. It goes like this in a hierarchy:
===> MASTER
===> DEVELOP
===> FEATURE
Master Branch
Origin/Master is the main branch where we have the production code.
To match it with our example above, Master will be only updated once, which is when the development work of Release-5 is finished and the new tests are running fine on Develop Branch. Now let’s understand What is Develop Branch.
Develop/Release/Integration Branch:
Origin/Develop is the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the current release.
In line with our example. this will always reflect the latest committed development work done for Release-5. Some would call this the “integration branch” or some “release-branch”. Integrate-Branch because this branch contains all the merged code of developed features, here the Production code integrates with new development code. Release-Branch because it holds the code of the new release. The idea behind this branch is to make sure that we don’t mess up the production code branch, which is Master in this example.
Feature Branch
This is a bit tricky I would say, just because people make use of this as per their understanding and their comfortability. Few people use this for per feature development by creating feature branches per feature. Some people use one feature branch for the whole team. Unlike the main branches, these branches always have a limited lifetime, since they will be removed eventually once the feature development is done.
With respect to our example, a team can have different feature branches for a per feature in a Sprint. But the purpose of the feature branches is to merge back to Develop branch ASAP. The guiding principle is to develop individual features in an as isolated manner as possible.
Assume you have multiple members checking in code for multiple features in the same Feature branch. It might happen that code for someone can break the build or introduce some bug in the feature branch which will hinder the work of other people working on the branch. To avoid such set bacs it is advisable that we have different feature branch for different features.
I will try to pick a question every week if I can.
Cheers
Lakshay Sharma
www.toolsqa.com
