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.

• Gitflow (Preferred for normal teams)
• Trunk based development (For mature teams)

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.

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.

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?

• Main - Start with the main branch often called master or trunk.
  • Name it 'main' lower case.
  • This is the default branch created when you create a Git Repository.
  • This should reflect the history of all changes gone to production.
  • Only select Leads should have the permissions to merge in this branch.
  • Only release or hotfix branches should be allowed to be merged into this branch.

• Development - This is the branch used by developers to create their own feature / story branches
  • Name it 'development' lower case.
  • This should be the branch used for all deployments to 'dev' environment.
  • Continuous Integration (CI) should be setup on this branch so that any merge commit will trigger a build process.
  • CI should be setup to run on any branch with development as target for merge.
  • Avoid giving permission to all the team members for direct commits to this branch.
  • A merge into development should be again controlled by select few (Leads).
  • A merge into development should be via a Pull Request.

• Feature Branch - This is the branch created by developer for implementing a feature.
  • All developer should follow a convention set by team for the naming of feature branches.
  • A Team can pick from any of the conventions listed below
    • feature/<story-id>_<feature_branch_name>
    • story/<story-id>_<story_branch_name>
    • <story-id>_<feature_name>
    • A branch for bugs can be named - bug/<defect_id>_<short_description>
    • Try to make use of all lower case when naming branches.
  • Changes in a feature branch should be small so as to make it easy for review
  • Keep pulling changes from development branches and forward merging it into feature branches on regular basis to avoid large conflicts towards the ends. (At least once a day)
  • A Feature branch is merged back into development only via a Pull Request that has undergone a process of code review

• Pull Request - This is how developers submit their changes for review and for merge into development branch.
  • It should be mandatory for all developers to raise a pull request for their change set.
  • All pull requests should have CI running on it.
  • Setup rules for allowing merging of a pull request like
  • There should be at least one approval (Preferred is two depending on team capacity)
  • All open tasks and feedbacks should be closed out before it can be merged.
  • Latest CI build run should be successful
  • Again restrict permission to only few (Leads) who can merge this pull request.

• Release Branch - This is the branch setup for shipping code to production.
  • Again use a convention to name release branches consistently.
  • Name it - 'release/<sprint_name_or_id>_<release_number_or_date>'
  • Release branch should correspond to sprint output to be shipped to production.
  • There can be bug fix branches pulled from release branches when bugs are discovered during regression and needs fixing before release is shipped to production. However, these too should follow the disciplines of pull request, code review and merge.
  • All deploy from release branch should be done to QA Environment using a build process.
  • Artifacts built for deploy to QA Environment should be preserved for simply promoting to Stage and Prod environment.
  • Once a release is dropped into the Production at that point Release branch should be merged into 'main' branch.

• Release Tags - These are labels that mark points in main branch when code was dropped into production.
  • Once a release branch is merged into the 'main' branch a release tag should be created on 'main' branch corresponding to the release.
  • Release tags should have a convention for naming.
  • Name it - 'tag/<release_branch_name>_<deploy_date>'
  • A Release Tag becomes the source for creation of a HotFix branch.

• Hot-fixes - Hot-fix branches is what you create when you want to ship an urgent fix to address a production issue.
  • Hot-fix branches should also follow a naming convention.
  • Name it - 'hotfix/<short_description>
  • These hotfix branch should be created from the latest release tag which reflects the code that was shipped in to the production.
  • Developers should pull their bug fix branches from this hotfix branch and target their pull requests to this same hotfix branch.
  • For deploy purposes hotfix branches should be treated like any other releases.
  • When hotfix is deployed to prod that is when the branch should be merged into 'main' branch along with tagging 'main' branch and syncing the 'development' branch with 'main' branch.