===== Some Customers Want Specific Environment Branches ======

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.

{{:programming:git:environmentbranches.png?nolink|}}

Based on the picture above, I create the QA branch off of the master branch using:<code bash>
git checkout -b qa master
git checkout -b prod qa
</code>

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:<code>
git checkout qa
git merge --no-ff master
</code>

When they are ready to do a deployment to Production based on the picture above, I use:<code bash>
git checkout prod
git merge --no-ff qa
</code>

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:<code>
git checkout develop
</code>