Defining Git Branching Strategy

Understanding git merge for your project

Introduction

Git one of the most favourite source control repository and its becoming, because its easy to use, you have command lines available and also you various user interfaces to manage your source code in Git.

Here in this blog we will discuss code merge approach which can be best suitable for your organization.

Lets Begin

Case 1: When you have feature and master branch only

When we start development generally we have feature branch e.g.: ‘feature/login-page’, developer develop their code in there and code gets merge to master branch….. here in this case you have an issue if you have team of multiple developer who are working on their own feature branch and their are also merging to master, in this case it might possible your master branch is not stable and it might have so many merge issues every alternate days.

Next Case:

Here in this case we have introduced a ‘development’ branch in between feature ‘branch’ and ‘master/main’ branch and your ‘master/main’ branch is locked so that there are NO direct check-in allowed into master branch, master branch only expect changes from development branch using merge policy which you apply on master branch, this is just to prevent any accidental changes gets merged into master branch from any source branch.

This way your different developers will be able merge their changes into ‘development’ branch and your CICD pipeline gets deployed from ‘development’ branch, this will make sure your development branch has got the code which is qualified to merge into master.

once you merge code into master branch you need to deploy your code with CICD again into various environments but this time using ‘master/main’ branch.

This looks good and you might think everyone is happy !!

Wait… are you sure everything is sorted ?

What if developer merge their code into ‘development’ branch and that code is merged into master branch without getting tested using their test cycle, in this case still there are chances you will have merging related bug into master or un-tested code get merged into ‘master/main’ branch.

How do you resolve this?

What is the correct branching strategy we should have ?

In my opinion we you are working with Git either on agile or any other model below strategy should work.

In this case we have following branches

‘feature’ branch: This is where developer team will work on their features.

‘development’ branch: This branch we accept changes from different feature branches…you should have a CICD configure from this branch so that developer can test their by deploying into various environment using that CICD.

‘release/v1’: This is the release branch which accept code merge only from ‘development’ branch using the branch policy. when your development branch is ready and stable you can merge code from development branch to release branch.

your release branch always pushed code into master branch is your production branch.

‘master’ branch: This is the branch which we should use to deploy code into production, this should have branch policy to accept changes only from release branches, and you branch should be locked otherwise.

We also need a CICD configuration here with master branch which we should be using to deploy the code into prod, make sure your CICD gets deploy code to all the environment not only to production, basically we need to have a round of verification test on master branch code just to ensure the code quality.

This is how your branch policy should look like.

I hope this is helpful.