One and a half years ago, one of our clients was experiencing serious deployment problems like on lot of merge conflicts on every merge,​ ​production database scripts and committed scripts are different resulting in wrong data schema, etc

We analyzed and concluded that root cause of problems is poor branching strategy. The client asked us to suggest the branching strategy that will work for them. We designed and implemented the updated Git branching strategy and solved the majority of deployment issues.

Following are the branching strategies for different development workflows that we implemented for the client.

Strategies for CI-CD based development

There will be four main branches created for each project and they are as follows,

1. Develop
2. QA
3. Staging 
4. Pre-Production
5. Main / Production

Below is the diagram that represents the strategy with the process automation and audiences,

Strategy for develop branch:

1. When a developer starts working on a feature, a feature branch will be created based on the developer branch. 
2. The code will be merged from the ‘develop’ branch to the feature branch daily. This is a manual step and it is expected that developers will do it on their own feature branch.
3. System will not do any code quality check on the feature branch. This branch will give leverage to the developer to make POC or write logic without worrying about the code quality.
4. Developers have to commit their code at least twice in a day either in the feature branch or in the develop branch.
5. All big features should be having a flag to turn on or off the feature. This will help to switch off the feature in the production. 
6. Feature branch should be removed from the repository once code gets merged in Staging branch. 
7. For merging code from the feature branch to the developer branch, the developer will have to raise a pull request.
8. The pull request has to be reviewed and approved by the reviewer. 
9. On completion, the requested code will be merged to the developer branch and the quality checks will be performed again (Build pipeline – Static Code Analysis, Unit test execution, Code Coverage). 

Strategy for QA branch:

1. For merging code from developer branch to QA branch, the Feature Lead will raise a pull request. 
2. The code will be merged to the QA branch on approval of the request by the Team Lead. 
3. A build pipeline will be executed for following checks,
   1. Unit test execution 
   2. Automation Testing 
   3. Integration Testing 
4. On success, a release pipeline will be triggered for automated deployment. 
5. In the case of any database schema changes CI/CD system should take a snapshot of the database and then make DB schema changes. This will help to revert the code in case any error comes. 

Strategy for staging and production branch:

1. For merging code from QA branch to Stage or Production branch, the lead level person will raise a pull request. 
2. The code will be merged to the Stage or Production branch on approval of the request by the lead level person. 
3. A build pipeline will be executed for following checks,
   1. Unit test execution 
   2. Automation Testing 
   3. Integration Testing 
4. On success, a release pipeline will be triggered for automated deployment. 
5. In the case of any database schema changes CI/CD system should take a snapshot of the database and then make DB schema changes. This will help to revert the code in case any error comes. 

For a bug in staging, a Hotfix branch will be created. This branch will be the copy of the Staging branch and will be treated as a feature branch. On successful build, the fix will be merged into the respective staging branch first and then will be ‘reverse merged’ into ‘develop branches. After this hotfix branch will be deleted.

For a bug in production, a Hotfix branch will be created that will be known as Pre-Production branch. This branch will be the copy of the Master branch. On successful build, the fix will be merged into the respective ‘pre-production branch’ first and then the pre-production branch will be reverse merged into staging and develop branches. After this hotfix branch will be deleted.

Git Branching Guidelines

1. We should create a feature branch for an enhancement or customization which is estimated for a minimum 5 days (the no of estimated days based on project and the size, structure, experience of your team you can change it according to your need)
2. Smaller bug fixes or features (less than 5 days efforts) will be typically directly done on the develop branch. However, the developer has to ensure that all code quality checks will pass.
3. Once a feature is delivered to Staging, the feature branch associated with it should be deleted.
4. If a feature takes more than 5 days to complete (consider 10 to 15 days), then at the end of each sprint the feature branch should be merged to the Development branch and then a new feature branch should be created based on the Development branch.
   1. The earlier feature branch should be deleted. The bug fixes for the delivered user stories will go into the new feature branch here on.
5. Reverse merge from the Development branch to feature branches should happen daily. As other developers will be parallelly working on the other features and will be committing them to the Development branch, will allow the developers to resolve the conflicts at an early stage.
6. Developers should frequently merge and push their changes to feature branches daily.
7. If a bug fix has huge changes or impact on various other modules, then we should create a branch from the Development branch and fix it there (should be treated as a feature branch).
8. The general bug fixes will directly go into the Development branch. No separate branch will get created for them.
9. Following are the tutorials/help for the Git plugin for managing the Feature and Hotfix branches
   1. Original Gitflow Proposal
   2. Gitflow Tutorial