A bit late to the party but I'm going to suggest something entirely different.
At my shop we often use a setup comprising simply of a develop branch, a staging (test) branch, and of course master (as the live productive branch), and we have build processes for both staging and master, which may differ slightly based on the test vs. live environment.
We only use separate branches for possible new breaking features that could cause hold ups in this chain. Otherwise, the work flow is develop on develop (obviously :) ), test on staging, and merge to master once all tests pass.
Indeed, we're a small shop, but I can't help but recommend having these three key branches. Even at a larger organization I could see this working, only maybe having more separate feature branches as branched off from the develop branch.
Do you do code reviews on committing to develop? Other companies/organizations generally have develop for work in between releases and merge into develop from feature/bug fix branches (primarily owned by one individual) with pull requests. The PR provides an opportunity for team code review and feedback before merging into the shared develop branch. That also allows developers to commit and push unfinished work to their own branches, so that it is backed up on their remote repository rather than just their own laptop. Otherwise if they pushed straight to develop, they'd constantly be breaking that shared branch with non-functional, partially complete code.
At my shop we often use a setup comprising simply of a develop branch, a staging (test) branch, and of course master (as the live productive branch), and we have build processes for both staging and master, which may differ slightly based on the test vs. live environment.
We only use separate branches for possible new breaking features that could cause hold ups in this chain. Otherwise, the work flow is develop on develop (obviously :) ), test on staging, and merge to master once all tests pass.
Indeed, we're a small shop, but I can't help but recommend having these three key branches. Even at a larger organization I could see this working, only maybe having more separate feature branches as branched off from the develop branch.