Automatic branch merging

Using branches in Bitbucket Server

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

Bitbucket Server can automatically merge changes to newer release branches, thus reducing the need for manual maintenance of branches. To be able to do this, Bitbucket Server has to be able to determine the ordering of branches, and relies on semantic versioning of branch names – for example Bitbucket Server will order these branch names like this: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.

Note that:

  • Automatic branch merging is subject to a few conditions.
  • Automatic merging is off by default for new and existing repositories.
  • You must explicitly enable automatic merging for each repository.
  • The commit message will indicate that the merge was automatic.
  • Bitbucket Server records full audit log entries for automatic merges.
  • Bitbucket Server sends notifications when automatic merges succeed (or fail).

As a project administrator, turn on automatic merging by going to Settings > Branching model for a repository, and selecting Enable automatic merging  (under 'Automatic merge').

On this page:

Conditions for automatic merging

The following conditions must be satisfied for Bitbucket Server to be able to automatically cascade changes:

  • The Bitbucket Server branching model must be configured for the repository.
  • The 'release' branch type must be enabled or a production branch must be set for the repository.
  • The merge must go via a pull request.
  • The pull request must be made to a branch that is of the 'release' type.
  • The target branch of the pull request must have branches that are newer than it.

Note that Bitbucket Server expects that the 'development' branch (commonly the 'default' branch) is always ahead of any 'release' branches. The final merge in the automatic cascade will be to the 'development' branch.

What happens if the automatic merge fails?

The automatic merge can fail for reasons such as:

  • Branch permissions prevent cascading changes to a particular branch.
  • Bitbucket Server detects a conflict that prevents the merge.
  • There is already an open pull request with the same source and target that the automatic merge would close.

For the first two cases, Bitbucket Server creates a new pull request for the failed merge, and the automatic merge operation stops. This allows you to 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).

Branch ordering algorithm

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

Bitbucket Server 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. 

Ordering examples

The table below provides examples of branch naming patterns that Bitbucket Server 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 Server tokenises 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 Server tokenises on the '.' and the '_' and orders the numeric parts of these branch names correctly.
BAD
  • release/1.0
  • release/bitbucket_1.1
Bitbucket Server tokenises on the '.' and the '_' but cannot recognise that 'bitbucket_1.1' should follow '1.0'.
Last modified on Sep 16, 2015

Was this helpful?

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