In my experience, working primarily based on integration branches, as opposed to working on master and cherry-picking back into integration branches, provides s

In my experience, working primarily based on integration branches, as opposed to working on master and cherry-picking back into integration branches, provides some short term benefits but is net negative in the long term. 1. People stop caring about master. Then master breaks and nobody fixes it. This is a problem if not _everyone_ is on the integration branch, e.g. if there is a single small team working on a feature for the next+1 release that needs master: they can't fix all the breakage from all the other teams, and they can't get the other teams invested in not breaking master. This ruins that teams productivity, which makes development of larger scale features much more costly. Even if no team needs master, leaving master broken and coming back to it later makes those fixes more costly. 2. Regressions: people mark bugs closed as soon as it is fixed in the integration branch. Then the fix never makes it into master, and you get regressions on the next+1 release. Automatic forward merge (always immediately and automatically merge release/n to release/n+1 [...] to master) as supported by e.g. Bitbucket can help with this, at the cost of the occasional merge conflict(s) and less control in case some fixes actually should not go into a specific intermediate release.