You deploy the branch you need to where you need to.
Now, obviously you aren't going to deploy a feature branch to production. But deploying the latest build from Master to development shouldn't be a problem.
The development branch in git-flow is about being the mainline - that from which the normal process has you branching off of and merging too. The only exception to this process is that of the hotfix branch where you need to grab the current from production.
Lets look at that hotfix a bit more and consider what the deployment process would be when you have three locations. You probably would deploy the fresh hot fix to dev, make some commits on that branch, and then deploy that to QA and then to prod.
For a normal release process with git-flow you are likely to be having builds off of the development server on development
branch. Once you branch for release
, you will likely have the head of the branch be going to the development server (so the devs working on the release effort can see what the current state is), and specific tagged branches going to QA. Once QA oks one of the tagged builds, the release branch at that tag gets merged into master
and then master
is tagged and deployed to production.
You will probably want to have multiple environments for dev. The head of release
is one deployment environment, head of development
is another deployment environment, and maybe even a head of feature
being another one or five.
You should be able to build any branch for any deployment environment profile. Deploying the current production to the dev server should be doable.
Git-flow itself is orthogonal to where you deploy things. It is about making sure that the different branches have a limited and defined set of roles that they take. By limiting the roles it makes it easier to reason about what each branch is doing and what its state is at any given time.
The only thing that git-flow tries to say about where specific things are deployed is that the head of master
is production. Anything else about what you deploy where in your environment is a site specific issue. Git-flow works just as well with only one production and devs doing all other deployments to their local servers as it does for having production, staging, qa, dev, and dozens of feature servers.
The steps for doing a deployment to any specific server are completely up to the local workflow for that server.