You should have a branching strategy

2021-08-21

What is Git Branching Strategy?

Software teams have to collaborate their work among the team members. This collaboration is managed effectively by setting up a clear strategy around how the source code will be made available to team members, how they will be able to manage their individual changes and track them, how they will make their individual code changes available to the entire team and then from where to pick up code for shipping to various environment.

So branching strategy is a strategy that a software development team employs when they are writing code, reviewing each others code, merging and shipping it to different environments with in the context of a version control system like Git.

Following Git Branching Strategies are popularly used.

I would suggest that teams start off with Gitflow branching strategy.

Gitflow Branching Strategy

Introduced by Vincent Driessen in 2010, Gitflow has become the more popular branching strategy adopted by teams. Here developers work off of a development branch by create their own feature branches from it and on completing the work merging their feature branch back into the development branch. This flow is easy to learn for developers. Though easy to learn and popular with most teams, yet it needs a discipline in team to ensure that feature branches are kept small, timely merges of release to master and from master back to development is carried out.

Gitflow

Release Process:

We should look at the release process closely in our branching strategy. Release branches are always pulled from the 'development' branch. This release branch should be pulled towards the end of the sprint but not on the last day. This is because we want to allow for QA to have some time regressing the release branch by deploying it in the QA environment.

One gap often seen with most team is that they continue to build from source code each time they carry out deployment to an environment beyond QA environment like Stage and Prod environments. This should be avoided. A QA certifies a build that is deployed in QA Environment, now if we carry out another build for deployment to Stage and another build for Prod then this new builds are different from what QA has tested. Such a build process has a potential to introduce issues in the final artifact that is being dropped, for this reason we should always preserve the QA Build and then propagate it through various environments.

Gitflow

Hotfix Process:

We should also look at the hotfix process closely in our branching strategy. Hotfix branches are always pulled from the release tags on the main branch. This is because release tags represent the code that was used for the build that was deployed to the production. So use this release tag to pull a hotfix branch and then team should be fixing issues against this branch. Once the fixes are done, use this branch to build and deploy to QA, and then use the QA certified artifacts for deploy to Stage and then to Prod environment.

How to setup Gitflow?