Automatic merge: Merge release branches forward only

abuob February 12, 2018

Our team wanted to enable automatic merging since having to do manual merges are kinda annoying. Our branching model is rather simplistic, we only have release branches - one for each month (release/18.1 is released at begin of January, release/18.2 in February; you get the idea).

What we did so far was manually merging the release branches into later versions, and we'd like to avoid that. We enabled the automatic merging feature, and for a while this seemed to work like a charm until a colleague recently wanted to merge something to release/18.3 (but !not! release/18.2), but automatic merge wanted to merge the entire 18.3-branch back to 18.2:

bitbucket-automerge.png

This is NOT what we want... automatic merges should be strictly forward only.

Now, to the question: What kind of setup would we need to achieve that? Is the behavior from above intended, is there an error in our setup?

I toyed around a bit with the settings, but haven't been able to find a solution yet.

If we need to adapt our settings or branch names in any way, we might do that, but we definitely want to stick with having some sort of 'monthly' release branches; a later branch always includes all commits of an earlier branch.
The branches created by the developer can have arbitrary names, usually it's either bugfix/... or feature/..., but we don't enforce that (yet).

Best regards & thanks for any help in advance :)

 

2 answers

0 votes
Ana Retamal
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 14, 2018

Thanks for your feedback! I've been searching our issue tracker and found this Feature request that you might be interested on https://jira.atlassian.com/browse/BSERV-7417. You can vote for it to increase its popularity, or add a comment if there's anything else you'd like to add / suggest :)

Hope that helps!

Ana

0 votes
Ana Retamal
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 13, 2018

 

Hi! 

Bitbucket determines what is merging to what based on the ordering algorithm, and we use Semantic Versioning to determine branch names. What seems to be happening here is that you're not using the correct naming for your branches, thus when you change something in 18.3 (minor version according to Semantic Versioning) it gets added to 18.2 too, since the Minor version adds functionality in a backwards-compatible manner. For more info I recommend you to read Semantic Versioning.

Follow the guidelines in the documentation Automatic branch merging to set the right names for your branches. Let us know if you're still experiencing the wrong behaviour after you do that, and we'll continue helping you.

Best regards!

Ana

abuob February 14, 2018

Thanks a lot for your answer, much appreciated!

This is very unfortunate for us. We're on a monthly release cycle (bugfixes/hotfixes go directly to the next version, big new features that rely on other systems to a release further down the road), so it's just natural that we have the year/month-numbers in our branch.

As far as I understand, renaming to our branches from release/Year.Month, something like release/Month-year would do (given that release/2-18 is already deleted when release/2-19 is created, which is always the case).

Frankly speaking, while I totally understand that there needs to be *some* kind of system, I definitely feel that 'semantic versioning' does not fit everyone's need - my team's software and the systems directly surrounding it definitely not. Some degree of customization that goes beyond toying around with branch-naming-patterns would definitely be appreciated.

dhilipb January 12, 2019

If that's the case, surely this shouldn't happen:

Screen Shot 2019-01-12 at 4.21.27 PM.png

Is there anything I'm missing?

Richard Navarro May 22, 2020

Hi Ana,

So if you are saying that the 18.2 version gets the code merged to it because 18.3 and 18.2 are backwards compatible, and because all MINOR and PATCH versions are backwards compatible, that would mean that MINOR and PATCH versions are essentially not taken into account when auto merging.

If I understand you correctly, that would mean that a PR to 18.5.3 would also merge to :

  • 18.5.4
  • 18.6.0
  • 18.6.1
  • 19.0.0
  • 20.0.0
  • 18.5.2
  • 18.5.1
  • 18.5.0
  • 18.4.0
  • 18.3.0
  • 18.2.0
  • 18.1.0
  • 18.0.0

Basically any release branch with a MAJOR version of 18 or greater.

Is this correct?

 

Because I would expect it to only merge to "newer release branches" as stated in the documentation on https://confluence.atlassian.com/bitbucketserver0610/automatic-branch-merging-989761281.html.  I would expect it to only merge to:

  • 18.5.4
  • 18.6.0
  • 18.6.1
  • 19.0.0
  • 20.0.0

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events