In a mature DevOps organisation would choosing a product/product line integration branch strategy be part of DevOps?
What do I mean by integration branch strategy?
For example a product team has to integrate 20 features in a certain interval of time to meet some time to market release requirements.
One potential approach would be to use feature branches in a waterfall manner as they've deen doing for years - each feature is developed and tested in their own branch and only merged into the main branch (from which the release branch will be pulled) after metting the respective feature QA goals.
But the total integration time estimate - 20 feature branch merge windows multiplied by the average merge duration (from the team's branch merge historical data) is maybe too high.
Another approach is to pull say 4 intermediate integration branches, each of which being used by 5 of the features branches. This way all 20 features will be integrated into the 4 intermediate branches in a 5 branch merge windows interval. Which would be followed by a 4 other branch merge windows interval for integrating these 4 branches into the main branch, bringing the total integration estimate to 9 windows, much better than 20. Yes, some of the gain will probably be cancelled by higher degree of difficulty of last 4 merges.
Another approach would be to go straight for trunk-based development (true CI integration into the main branch) with practically no branch merges.
The process of selecting one such strategy is what I'm referring to as branch strategy.
Note: the actual SCM repository is irrelevant, it can be any combination of repos managed together as a single one, the term
branch denotes just the common logical representation of whatever physical/actual repo branches exist in that combination.