Checks for merging pull requests
To help customize your workflow, you can set checks to control when a pull request can be merged. Pull requests cannot be merged if the required checks have not been met. These checks are set separately on each repository in a Bitbucket Server project.
You'll need either project admin, admin or sys-admin permissions to set merge checks for pull requests.
To set checks for merging pull requests, go to a repository in a project and choose Settings > Pull requests. Bitbucket Server includes the merge checks described below, or you can write your own merge request check plugin.
Requires a minimum number of approvers
Stops a pull request from being merged until it is approved by at least the selected number of participants.
Requires all reviewers to approve the pull request
Stops a pull request from being merged until all reviewers approve a pull request.
Requires all tasks to be resolved
Stops a pull request from being merged if any pull request tasks are still unresolved. Read more about Review and discuss a pull request.
Requires a minimum number of successful builds
Stops pull requests from being merged if they have any unsuccessful builds. For a pull request, this checks builds that run against the latest commit on the source branch.
You must also specify a minimum number of builds - the pull request will not be able to be merged until at least this many builds have completed. Ideally, you should set this to the number of different builds that are configured to run against the branches in your repository.
See the page Bamboo integration for more information about integrating Bitbucket Server with your build server.
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.
About merge strategies
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:
| Merge commit | --no-ff | 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. |
|---|---|---|
| Fast-forward | --ff | 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. |
| Squash | --squash | Combine all commits into one new non-merge commit on the target branch. |
| Fast-forward only | --ff-only | 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 | --squash --ff-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.
