0

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?

Cedersved
  • 1,015
  • 1
  • 7
  • 21
  • Why not merge `development` to `master` once `feature` is done and pushed? I can't see any downside with your idea except the one you have mentioned, but it makes branching a bit complex. I usually make a `release` from `development` after testing on `test` to deploy on `prod`. Then merge `development` to `master`. – Talkhak1313 Feb 13 '23 at 07:24
  • 2
    @Talkhak1313 Because you do not merge integration branches together: some feature merged in `dev` might not be ready for `master`. If you have only one feature branch, yes, why not. But in the projects I see at work, there are *many* feature branches, with various maturity state. – VonC Feb 13 '23 at 07:26
  • 1
    Your suggested procedure makes a *lot* of sense. Having to solve merge conflicts is not a downside. And if it's done in the same repository, the rerere database can help a lot. – j6t Feb 13 '23 at 07:26

1 Answers1

0

Once the feature has been tested, the same feature branch will merged with another pull request into the master branch, for deployment to production.

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250