I work on small team with other remote developers on a Rails application. We are starting to modify our git workflow. We have thought about a branching structure like below:
(dev) -> (qa) -> (stag) -> (master)
But some of the developers thought it might be less confusing for new developers who might automatically push to production on master. They thought instead to have everyone work on master and create a separate branch for production.
(master) -> (qa) -> (stag) -> (prod)
I was taught you want to keep master deployable and not use it as development and from previous places where I've worked master is always meant to be deployable for production.
What would be some of the disadvantages of using a branching structure where master is actively used for development and a separate prod branch is what you use for deployments?
Best Answer
There are neither any advantages nor disadvantages to this approach. The reason I say this is simple: to Git, it makes no difference if you develop from master or release from master. You don't even need to release branches; you could tag an arbitrary commit and release that, instead.
The real trouble here is one of process and procedure. The more senior devs that are concerned that doing it in one way will confuse the newer devs need to be prepared to invest the time to explain what the release model is and why it's that way.
So long as everyone understands that master is for development, and some other arbitrary branch is for releases, and the work to maintain this is done, then there shouldn't be any problems with this approach.