Automatic branch merging

Using branches in Bitbucket Server

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

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.

注意:

  • 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').

このページの内容

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 or the 'production' branch.
  • 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 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 Server tokenizes on the '.' and the '_' and orders the numeric parts of these branch names correctly.
BAD
  • release/1.0
  • release/bitbucket_1.1
Bitbucket Server tokenizes on the '.' and the '_' but cannot recognize that 'bitbucket_1.1' should follow '1.0'.
最終更新日 2017 年 9 月 20 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.