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:
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 :)
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.
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.
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!
As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs