The fact is that this doesn't work for everyone. What we found to be most workable is master is always "stable", then we have a production branch that is cut from master.
This gives you a few things:
1. More predictable deployments (let's deploy every week with X items)
2. Better rollbacks (rollback to last production deploy instead of guessing SHA1 of last acceptable state)
I've also seen people have a single development branch and multiple release branches (imagine a 'devel' branch that everyone merges into and a branch for each release that you have, and that potentially merges back into devel if you do hot patches). It's essentially the same thing -- branches aren't really all that different than tags in git.
Yeah its basically aesthetics. I do like keeping the release identifier separate from branches though just for categorization purposes (branches = development, tags = releases)
we deploy to test multiple times a day from out master branch after a Pull request is reviewed & merged. the deployment bundle (zip of the state of the code) that goes to test later goes to staging and production is the same across environments.
The only thing that changes is the configuration variables which are replaced at each env.
This ensures predictable deployments and if we want to rollback we just pick the last release bundle and re-deploy that.
My snarky version of this is: ideally head of master is deployable (no regressions, yadda yadda). In reality, how many times has head master of master been broken and one had to rollback, and then had to scramble to find the rollback?
Gitflow is fine - better to use it (w/the girl extension) than spend time arguing branches.
This gives you a few things:
1. More predictable deployments (let's deploy every week with X items)
2. Better rollbacks (rollback to last production deploy instead of guessing SHA1 of last acceptable state)