Pull request merge strategies
Git merge strategies affect the way the Git history appears after a merge has occurred. With Bitbucket Server 4.9, repository admins can choose which merge strategies to allow, and set a default merge strategy. And users can now choose a merge strategy from the merge dialog of each pull request.
Prior to Bitbucket Server 4.9, you could choose a merge strategy within the configuration file, but you would have to use the same merge strategy for all pull requests within a repository. And, changing merge strategies required you to restart the instance, which could cause disruption to sysadmins and downtime for end-users.
The merge strategy options are:
Always create a new merge commit and update the target branch to it, even if the source branch is already up to date with the target branch.
If the source branch is out of date with the target branch, create a merge commit. Otherwise, update the target branch to the latest commit on the source branch.
Combine all commits into one new non-merge commit on the target branch.
If the source branch is out of date with the target branch, reject the merge request. Otherwise, update the target branch to the latest commit on the source branch.
Squash, fast-forward only
If the source branch is out of date with the target branch, reject the merge request. Otherwise, combine all commits into one new non-merge commit on the target branch.
To configure merge strategies for a repository:
- In repository settings, select Pull requests.
- In the Merge strategy section, tick the box next to one or more merge strategies to determine which strategies are available to users when merging pull requests.
- Once an option is enabled you can set it as the default merge strategy for that repository by clicking Set as default.
To change the merge strategy for a specific pull request
- When merging a pull request, click the default merge strategy in use, then select a new one.
- Add a comment (if applicable), the click Merge.