[Other doc versions]
The following conditions must be satisfied for Stash to be able to automatically cascade changes:
Note that Stash 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.
The automatic merge can fail for reasons such as:
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 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).
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:
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'.|