I am the DevOps/CI for my team of somewhere around 10 developers. We develop and implement a sophisticated scientific data collection and visualization web application. I am the person who introduced CI to my team and standardized and streamlined the build process using Jenkins, Maven, Python etc. We use Subversion for versioning, which is not my preference (of course, Git is) but I can work within those parameters. The subject of this inquiry is our branching strategy, which I am trying to promote into a policy.
As someone who manages all of the lifecycle past the point of checking changes in, my preference is to have not have to support more than two branches of code: (1-PROD) that which is currently deployed in PROD and (2-DEV) that which is in development. This simple scenario makes my life easy and the lack of flexibility with regard to branches is what enables efficiency and smooth operation in my department. Having a single, unified branch per release, and not having feature branches, eliminates the need for merging, which is something that is always a crapshoot, to put it mildly. So, the model I am proposing would, in theory, require to never merge anything -- if a developer makes PROD fix changes in 1-PROD, (s)he is responsible to apply those changes to 2-DEV, so that we don't have to do merges in the CI process. Keeps things neat and stable.
However, there is a tendency within the team as well as the management to resort to creating a new branch whenever the slightest discrepancy in requirements arises, and many of those challenges could be addressed within the same branch, e.g. by toggle switching the pending functionality using configuration until it is ready etc. In every instance of a new branch that has been made, I demonstrated that the isolation of the development effort could be accomplished within the existing branch using configuration settings. I wouldn't hate is as much if they didn't also require that official build artifacts be generated and deployed to various testing instances from those branches (PROD deployment always goes out from the main branch after any possible feature branch has been integrated). So if they want to have 100 branches for developers, that's fine by me as long as they are responsible for merging them into one of the two branches that affect me and I don't have to support deployment from there to actual instances. I would also hate it less if multiple branches didn't involve the awful process of merging, which I absolutely hate and strive to design an environment in which it's not done.
Is my proposed branching/deployment strategy (to support only the two canonical branches in the integration process) unreasonably simplistic? Is the complication/entanglement associated with branching flexibility simply a fact of life in the world of DevOps/CI?