automatic branch merging - backport only the feature

[Christophe Bailly]

Hi,

I would like tio use the automatic branch merging feature but here is my problem.

Suppose I have branch release/1.1

If I merge a pull request and my target branch is 1.1, then it will merge my feature into 1.1 and trigger also a merge of 1.1 into master.

The problem is that during the merge to master, it may include other devs present in 1.1 and not in master besides the feature I want to include... How to make sure that only my feature branch will be backported to 1.1 and master ? There may be developments specific only to branch 1.1

If I switch to another merging strategy, will it behave the way I want ?

Thanks in advance,

[Mark A_]

Hi Christophe,

This sounds as if your branching strategy is not allowing you to have the flexibility you want.  From my past experience, the only dev features that should be present are those approved to be in 1.1.

In my days in SCM, while we did have Master, that was untouched and only Production branch could be merged to it. We also had a Development branch that devs branched from, and we had our platform branches for testing. Once PR'd into a Release branch, the changes were locked and released (merged) to Production, and ultimately back to Master.  This was just how my team worked things. Definitely check out another Community post on Branch Management with Bitbucket.

To get back to the crux of your question if I am understanding it correctly - yes, if release/1.1 is open for anyone to merge their changes, those changes will carry on to Master if and when you decide to merge into release 1.1.

There is nothing automatically set in Bitbucket Server that would prevent or cherry pick only your feature to merge to 1.1 only. If there are other branches matching the semantic versioning, they will get updated with all changes through automatic merging.

It would be best if those devs had their own feature branches to develop and play in along with potential platform branches that deploy to Dev/Test/Beta, etc., and then restrict your release branches using branch permissions to only allow changes via Pull Requests and require an approver.

If Master is not your development branch, then you can change what this is in the branching model configuration, this will change where the changes are ultimately auto-merged to and you can control merges to Master manually. 

Let me know if you have any other questions.