Automatic branch merging
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 |
| Bitbucket Server tokenizes on the '.' and the '-' of '1.1-rc1' and is able to order these branch names correctly. |
GOOD |
| Bitbucket Server tokenizes on the '.' and the '_' and orders the numeric parts of these branch names correctly. |
BAD |
| Bitbucket Server tokenizes on the '.' and the '_' but cannot recognize that 'bitbucket_1.1' should follow '1.0'. |