Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Automatic merge: Merge release branches forward only

Edited

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 Feb 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 Feb 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

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.

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?

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
Community showcase
Published in Bitbucket

New improvements to user management in Bitbucket Cloud 👥

Hey Community! We’re willing to wager that quite a few of you not only use Bitbucket, but administer it too. Our team is excited to share that we’ll be releasing improvements throughout this month of...

3,756 views 10 16
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you