Git – Auto-merging from master to all branches — good or bad idea

TL;DR: your git workflow isn't really the problem. The problem is that you need more, smaller iterations on the features you put in your topical branches. This will reduce the pain of keeping these topical branches up-to-date and integrating them into the upstream.

You definitely want to keep unmerged branches up-to-date with the changes in their upstream, and rebasing is generally the correct way to do this.

Your comment that "sometimes a feature is bigger than what a branch should be" leads me to believe that you have long-running topical branches that you find difficult to integrate with your integration branch. This, in my experience, is the actual root of your pain.

Imagine if your topical branches lasted a few hours and then were merged back in to the integration branch. These ephemeral branches are likely to be trivial to keep up-to-date and trivial to merge back into your integration branch. On the other hand, imagine a long-running topical branch that spans multiple releases of the software without integration. It would probably be quite difficult to integrate. This should lead you to conclude that short-running topical branches that are frequently rebased against master are easier to work with.

The question, then, becomes "why would features be bigger than what a branch should be?" This is probably because you're trying to do too much at once. The best way to keep topical branches short-lived and to make integration painless is to work in an iterative fashion where the minimum marketable feature is ruthlessly hewn down to its bare essentials and further work on that feature is added on in separate increments.

My general take on the best practices is that any member of the development team should be able to perform any action on the tree presuming those actions don't do things like kick off a production deployment. In cases where a specific branch / tag / repository does act as a source for automated deployments putting in some reasonable change control or barriers to entry make sense, more from a keeping mistakes merely mistakes perspective than some control-freak angle. I would encourage developers to create branches and improve the build scripts. I would find ways to get developers access to production if needed. Part of the point of source control is it is an effective magic eraser of mistakes -- the worst you'll need to do is roll back a rev or two and branch off that.

Unfortunately this doesn't sound like the approach they have taken here. In order to defeat this I think you need to cover a few angles:

a) Prove that these policies are detrimental to developing things. Log all the time you spend waiting on ops to get working on something. This alone should sell reasonable management on why this is a bad policy.

b) Make some friends in Ops -- perhaps there is a reason for this policy. Perhaps that reasoning could be addressed in a more effective manner.

Hope this helps.