Downsides of merging feature branches based on master to another collaboration branch AND to master?

[coincatcher22]

Select Topic Area

Question

Body

Today I'm working with a trunk-based development styled branching strategy, which is not optimal from a deployment and collaboration perspective for different reasons. I have an idea to replace this with something else, for the work we're doing with our Azure based data platform consisting of several different Azure products (with different code masses).

To support CI/CD and flexible collaboration, I do not want to have release branches and I do not ever want to merge a development typed collaboration branch to the main/master branch.

My idea is to have the 'master' branch correspond to the code running in production, and to create a (basically forever living) collaboration branch named 'development' based on master (or possibly a fork?). Then for the ongoing development work the developers would create a feature branch based on master, that will be merged with pull request into the development branch once the feature development is done and the code should be deployed to DEV/TEST environment. Once the feature has been tested, the same feature branch will merged with another pull request into the master branch, for deployment to production.

I can see one obvious downside with this branching strategy, which is that merge conflicts would have to be solved two times. Once when merging to the development branch, and again when merging to master.

Are there any other downsides with this type of branching strategy?

[smartman0307]

Yes, exactly! You do not merge integration branches to other integration branches (branches like dev, release, main, ... where you integrate multiple feature branches together).
Merging the same feature branch to different integration branches allows you to choose precisely the features ready to go to the next delivery stage.

Integration branches are long-lived branches you are merging to, not from.

I have described that process before as gitworkflow (one word)

The downside is: what you are building in one branch is not exactly what you end up building in another, because you do not always chose the full set of feature branches merged in one integration branches when you are merging said feature in the other.

That means the artifact built from one integration is not always the same.
But as long as that artifact is still delivered across all the deployment environment (dev/test/pre-production/production), that should not matter.

[tuves]

GitHub's Acceptable Use Policies prohibits coordinated or inauthentic activity like rapid questions and answers. As a result, we'll be unmarking the answer and locking this post. Please note any future violations may result in a temporary or indefinite block from the Community. Thanks for understanding.