Automatic Merge Not Working

[Ji Yong Park]

As a user of Atlassian BitBucket server, I was looking into the automatic merging feature you guys have built in. It definitely was something I was looking for, so tried to use it, but had no luck.

I have a master (prod), develop, release/1.0, and release/2.0 branches. I made changes to release/1.0 and created a pull request to merge it to develop branch. By enabling automatic merge, I would expect it to merge the changes to release/2.0 as well, but it won't. Same goes for the case if I create a pull request from release/1.0 to master. It will only merge down to develop and not to the release branch.

Could anyone help me out? I am using 4.9.1 of BitBucket.

Thank you!

[Ana Retamal]

Hi Ji! There should be more than 3 branches and should be in sequences. All the branches should have their own update from the previous version. They should look like this:

• release/1.0
• release/2.0

• release/2.1

• release/2.2

Also keep in mind that auto-merge does not work in backward manner, only sequence upwards.

If that still doesn't work for you, you can try naming the branches using semantic versioning, this means they need to have major, minor and patch positions. 

Let us know if this helped you!

Best regards,

Ana

[Ji Yong Park]

Hello Ana,

Thank you for taking the time to answer the question. I really appreciate it.

I have tried with 3 release branches as you said, but still get no cascading merges happening. In my example, I have release/2.0, release/2.1, release/2.2. I tried merging the pull request from release/2.0 into develop, which did not trigger any downstream merges.

Also wasn't sure if having 3 branches was a requirement in the documentation, and why it would be one. Could you explain to me why that is the case?

Thank you!

[Julius Davies [bit-booster.com]]

I'm releasing a new enhancement to my paid add-on tonight (Bit-Booster - Rebase Squash Amend), and part of this work required me to thoroughly experiment with automatic merging yesterday and today.

So here's the thing:

Merges into "develop" will never cascade.

Only merges into release branches or production branches will cascade up.

If you want to see a full cascade based on your setup, try this:

git checkout release/2.0
touch a.txt
git add a.txt
git commit -m 'to see cascade'
git push origin HEAD:refs/heads/fix-for-2.0

And then create a pull-request to merge this new "fix-for-2.0" branch into "release/2.0".   Right away on the pull-request merge dialog you'll see that it wants to do the cascade:

Some additional notes:

- Auto-merge only happens for changes that arrive via PR.  Direct pushes never trigger auto-merge.

- If there's already an open PR for one of the steps of the cascade, then that step will be skipped.  e.g., if "release/2.0 --> master" was already sitting in an open PR, then the auto-merge will defer to that.

[Ji Yong Park]

So in short, direct pull request of a release branch into develop does not cascade, but pull request of a feature branch into release branch does cause the cascade. This is definitely some valuable information.

I got my branches to work correctly now. 

Thank you for such a clear explanation!

[Julius Davies [bit-booster.com]]

My pleasure!

[claudiu]

Hi,

We are tsting the Automatic merge model, and looks it not create the PR for resolving the conflicts.

It skip them, and merge into the branches without conflict only.

Is a option for creating the PR for resolving the conflicts?

How a developer will know he need to resolve the conflicts?

For example:

1. created a PR for merging a branch into release /1.0.0  but meantime somebody else already merged into master some changes;

My PR will merge only into release and will skip the master.

Not creating the conflict PR

2. Also in case of using only release 1.0.0 and release/1.2.1

Will not resolve the conflict for release 1.0.0

Any activation required for creating the conflict resolving PRs ?

[claudiu]

solved by checking the PR which rules which required  at least one reviewer