Automatic branch merging

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

Bitbucket Data Center and Server can automatically merge changes to newer release branches, reducing the need for manual maintenance of branches. This page describes best practices for establishing a branching strategy conducive for automatic branch merging, and how to enable it for individual repositories or all repositories in a project.

Conditions for automatic merging

In order to use automatic branch merging, Bitbucket has to be able to determine the ordering of branches, and relies on semantic versioning of branch names. For example, Bitbucket will order these branch names like this: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. Read more about the Branch ordering algorithm, including some examples of branch ordering, later on this page. Bitbucket expects that the 'development' branch, typically the default branch, is always ahead of any 'release' branches. The final merge in the automatic cascade will be to the 'development' branch.

These conditions must also be satisfied:

  • branching model must be configured.
  • The 'release' branch type must be enabled or a 'production' branch must be set.
  • The merge must be made using a pull request to a 'release' or 'production' branch type.
  • There must be newer branches than the target branch of the pull request.

Good to know:

  • Automatic merging is off by default.
  • Commit messages will indicate a merge was automatic.
  • There are audit log entries for automatic merges.
  • Notifications are sent when merges succeed or fail.

What happens if an automatic merge fails?

When an automatic merge fails, Bitbucket creates a new pull request for the failed merge, and the automatic merge operation stops. You should resolve the conflict locally before approving the new merge, which may start a new series of cascading merges. Note that a pull request that gets automatically opened when a merge fails won't trigger the continuation of the initial merge chain if resolved locally (which is the approach that we recommend).

There are a few reasons an automatic merge could fail:

  • There could be a conflict detected that prevents the merge.
  • There is already an open pull request with the same source and target that the automatic merge would close.

Example scenario of what happens when an automatic merge fails

For example, if you have multiple release branches, R1, R2, R3, and R4, they can all automatically merge into one another with automatic merging enabled. I.e., If you merge a pull request to R2, it will automatically merge R3 and R4 until you get to the development branch.

With automatic merging on, let's then say that there is a merge failure with R4. If you merge to R1, then Bitbucket merges to R2 and R3, but cannot merge to R4 because of the conflict. Bitbucket then opens a pull request from R3 to R4. The pull request is assigned to you because you attempted to perform the merge. Conflicts will need to be resolved and there are chances you may not even see that there was a pull request created.

There are two options available for how merging pull requests upstream from the conflict will behave:

  • Allowed to merge but only to the pull request opened for the merge conflict. This means that the next time a merge is attempted, there will be a warning stating that there is an open pull request downstream.
  • Blocked from merging until the pull request that was opened for the merge conflict is resolved. This means that any merging is blocked because of the open pull request downstream.

Enable automatic branch merging

You can enable automatic branch merging for all repositories in a project, and choose to inherit or override this setting in individual repositories. 

Enable automatic branch merging for all repositories in a project

All repositories in a project can inherit or override the branching model, including automatic branch merging. 

To enable automatic branch merging for all repositories in a project (requires project admin permission):

  1. Go to Project settings > Branches.
  2. Under Automatic merging, select the On status and then select Save.


Enable automatic branch merging for a single repository

To enable automatic branch merging for a single repository:

  1. Go to Repository settings > Branches.
  2. Under Automatic merging, select the On status and then select Save.

Branch ordering algorithm

Bitbucket is able to automatically merge changes to newer release branches, as long as Bitbucket can determine the ordering of those branches. Ordering is based on semantic versioning in the naming pattern for branches.

Bitbucket uses the following ordering algorithm to determine the branches in the merge chain:

  • Branches are selected and ordered on the basis of the name of the branch that started the cascade (i.e. the target of the pull request for the merge).
  • Branch names are split into tokens using any of these characters: underscore '_', hyphen  '-', plus '+', or period '.'.
  • Only branches matching the name of the pull request target are added into the merge path. Matching means that every token before the first numeric token must be equal to the corresponding tokens of the target branch's name.
  • Branches are ordered by number, if a given token is numeric. When comparing a numeric token with an ASCII token, the numeric is ranked higher (i.e. is considered as being a newer version).
  • If both tokens are non-numeric, a simple ASCII comparison is used.
  • In the unlikely case of the above algorithm resulting in equality of 2 branch names, a simple string comparison is performed on the whole branch name.
  • There is a limit of 30 merges. 

Branch ordering examples

The table below provides examples of branch naming patterns that Bitbucket is able, and not able, to order correctly:

GOOD
  • release/1.0
  • release/1.1-rc1
  • release/1.1
  • release/1.2
  • release/2.0

Bitbucket tokenizes on the '.' and the '-' of '1.1-rc1' and is able to order these branch names correctly.

GOOD
  • release/bitbucket_1.1
  • release/bitbucket_1.2
  • release/bitbucket_2.0

Bitbucket tokenizes on the '.' and the '_' and orders the numeric parts of these branch names correctly.

BAD
  • release/1.0
  • release/bitbucket_1.1

Bitbucket tokenizes on the '.' and the '_' but cannot recognize that 'bitbucket_1.1' should follow '1.0'.

Last modified on Jul 27, 2021

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.