Branching Strategy simplified for any production-ready projects

If you’re working as a team and your project is live in production, the team should follow a policy during code commits, delivery, releases and bug fixing.

It’s tough to finalize one, but as per my past experience, we can go ahead with the GitFlow model. If you’re reading this, I’ll suggest the team shall start adopting the branching strategy (GitFlow model) from their next release, sooner will be better. There will be only two permanent branches — master and develop and rest all others will be temporary.

Git Branching strategy

Below is the summary of the GitFlow model :

All the features will be done on a feature branch, branched off from Develop and will be merged to develop once the feature is complete. It will be the responsibility of the feature guy to ensure the PR is always against the updated source develop branch with no conflicts.

  • All the code reviews will happen under this PR

With this PR being merged, the develop will contain the addon latest feature code and will require proper testing/QA to plan the release. For the preparation of the release, a release branch will be branched off from develop and will be deployed on staging for testing and validation.

  • During the test run on staging, if we get any issues, a bugfix branch will be branched off from this release for all the fixes identified in this run
  • This bugfix branch will be merged with the release branch and will also be merged with develop to ensure develop branch always contains the bug-free code.
  • All the issues identified here will be raised in JIRA with the environment as Staging
  • And then, the bugfix branch will be closed.

Once the release branch will be signed-off after the proper QA, we will merge the release branch with the master.

  • And then, the release branch will be closed.

Then, the master branch will be deployed on the pre-prod server for a demo run before we go-live on client instance.

  • During the pre-prod run, if we get any issues, a hotfix branch will be branched off from this master branch for all the fixes identified in this run
  • This hotfix branch will be merged with the master branch and will also be merged with develop to ensure develop and master; both branch always contains the bug-free code.
  • All the issues identified here will be raised in JIRA with the environment as Pre Prod
  • And then, the hotfix branch will be closed.

Once the pre-prod run will be successful with 0 issues, we will go for the client deployment, the real go-live for our team. The master branch will be deployed on the client-server instances.

  • During the client pipeline run, if we get any live issues, this calls for the P0/P1 issues only and only if they are obstacles for the output generation or client seamless experience. Else, we can go for P2/P3 as well.
  • The issues identified here will be raised in JIRA with the environment as Prod — the actual P0/P1
  • The hotfix branch will be branched off from this master branch for all the fixes identified in this run
  • This hotfix branch will be merged with the master branch and will also be merged with develop to ensure develop and master; both branch always contains the bug-free code.
  • And then, the hotfix branch will be closed.

Feel free to reach out to me at: https://www.linkedin.com/in/ashutosh-kumar-9a109864/

Backend Engineering | BIT Mesra | Building Microservices and Scalable Apps | Mentor