I prefer to handle deployment to specific environments via a deployment script where I can ensure that all environments are setup the same way and configured similarly while still allowing variation between environments such as load balancing or a geo-based URL for the back-end. It also allows for new configuration settings to flow through the deployment pipeline easily. However, some customer have setup their deployment environments to track a specific environment branch such as QA, Integration, Staging, Production, etc. and sometimes they want a specific configuration that is different from other environments. Trying to do this within the Gitflow branching scheme that I prefer is difficult since the “release” and “hotfix” branches are short-lived and are deleted as part of the merging flow.

To accommodate these customers, I've “slightly” modified the Gitflow process to create these environment branches off of the master branch.

Based on the picture above, I create the QA branch off of the master branch using:

git checkout -b qa master
git checkout -b prod qa

I then continue my normal workflow with “potentially deployable code” sitting in the master branch. When the customer is ready to deploy to QA, I will then come back to that environment branch and:

git checkout qa
git merge --no-ff master

When they are ready to do a deployment to Production based on the picture above, I use:

git checkout prod
git merge --no-ff qa

I use –no-ff because creating the merge commit forces the customer's CI server to see a “change” and then proceed to build and deploy the application and allows me to see which commit is deployed to the environment.

After, the deployment, I return to the development branch:

git checkout develop