git branching strategy – what’s yours?

When it comes to deploying code to various environments, the ideal scenario would be to continuously deliver a specific branch to production, after delivering to dev/test/staging with unit tests to validate the code on the way. The other end of the spectrum is to manually deploy and test to each environment. All clients I work with are comfortable somewhere in between where deployments are automated to pre-production environments where validation can be performed manually and then production deployments are triggered manually with immediate human validation.

What does this have to do with git branching, you say? If you don’t deploy code to production immediately, it’s a good idea to logically mark it as different than what is in production. The most common logical markers used in git are branches and tags. A branch is a copy made from another branch that then becomes a seperate code base within the repository while the tag is a very specific commit hash that transcends branches and is applied repository wide. A branch may be merged with other branches while a tag remains static.

There are three primary strategies to deployments with these logical markers:

• creating a tag for all deployments and deploy the tag
• creating a branch which applies to each environment – deployments are triggered by merging with that branch
• creating a branch for pre-prod work and deploying master to production

I’ve created the list based on the order that I have seen them applied with various clients I work with and have worked with in the past. The most fool-proof strategy that I have seen by far is the strategy to create a branch for each environment and auto-deploy by merging into that branch. That strategy can easily be implemented in Jenkins by creating a job for each environment and setting the branch in the configuration.

If you create a tag or new branch for pre-prod work and plan to deploy that to staging, for example, you must specify somewhere that you want to deploy that tag or branch and this creates more of an interactive deployment situation. The more interactive the process is, the more potential for error. Also, if you work with a large team and you’re coordinating deployments, you must be very clear as to which branch/tag gets deployed [and has been deployed] to each environment.

What’s your strategy?