Stash can automatically merge changes to newer release branches, thus reducing the need for manual maintenance of branches. To be able to do this, Stash has to be able to determine the ordering of branches, and relies on semantic versioning of branch names – for example Stash 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.
- Stash records full audit log entries for automatic merges.
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 Stash to be able to automatically cascade changes:
- The Stash branching model must be configured for the repository.
- The 'release' branch type must be enabled 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.
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.
- Stash 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, Stash 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 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
Stash is able to automatically merge changes to newer release branches, as long as Stash can determine the ordering of those branches. Ordering is based on semantic versioning in the naming pattern for branches.
Stash 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 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 Stash is able, and not able, to order correctly:
| GOOD |
| Stash tokenises on the '.' and the '-' of '1.1-rc1' and is able to order these branch names correctly. |
| GOOD |
| Stash tokenises on the '.' and the '_' and orders the numeric parts of these branch names correctly. |
| BAD |
| Stash tokenises on the '.' and the '_' but cannot recognise that 'stash_1.1' should follow '1.0'. |
