プル リクエストのマージ
Once you are ready to merge a pull request, and when the reviewers have approved it, click Merge at the top right of the pull request view. You can merge a pull request if you have write (or admin) permission on the project.
Bitbucket Data Center and Server does not enforce particular review workflows, so anyone with write permission on the repository can merge a pull request, including the person who opened it. This flexibility allows different teams to have different approaches to using Bitbucket. If your team requires stricter control, consider using branch permissions to restrict who can merge a pull request to particular users or groups. You might also want to consider using a plugin to enforce a particular workflow, for example to ensure that only approvals from members of your review team allow merging. See the page Checks for merging pull requests for details about enabling merge checks.
In the Merge pull request dialog, you can add information about the pull request in a comment. The text you add appears between the subject line and the log lines that Bitbucket and Git generate, and adds the text to the commit message for the merge.
The Merge pull request dialog
Delete source branch after merging
When merging a pull request, you can choose to Delete source branch after merging. This setting is selected by default to help you keep your branch list clean. If this isn't your preferred setting, you can change it, and your preference will be saved for next time you merge a pull request.
If you choose to delete the source branch, any open pull requests targeting the source branch will be retargeted to the target branch. Select the affected pull requests link within the dialog to view the pull requests that will be modified.
Before deleting your source branch, Bitbucket will do some checks. The branch being merged will not be deleted if:
- The branch is the default repository branch.
- The user does not have permission to delete the branch.
Once accepted, the pull request is marked as merged on the Pull requests tab. If Bitbucket detects a conflict that prevents the merge, notifications are displayed on the Overview and Diff tabs of the pull request. Click More information to see instructions for how to resolve the conflict in your local repository.
Choose a merge strategy
Git merge strategies affect the way the Git history appears after a merge has occurred. You can choose a merge strategy from the Merge pull request dialog. Administrators can configure which merge strategies are available and which merge strategy will be the default.
To change the merge strategy when merging a pull request, click the merge strategy in use (next to the Merge button), then select a new one.
The merge strategies available in Bitbucket are:
- Merge commit (
--no-ff) DEFAULT: 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. - 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. - Rebase and merge
(rebase + merge --no-ff): Commits from the source branch onto the target branch, creating a new non-merge commit for each incoming commit. Creates a merge commit to update the target branch. The PR branch is not modified by this operation. - Squash (
--squash): Combine all commits into one new non-merge commit on the target 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.