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.
[プル リクエストのマージ] ダイアログ
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:
- ブランチが既定のリポジトリ ブランチである場合。
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.
Git のマージ戦略は、マージ後の Git 履歴の表示に影響します。マージ戦略は [プル リクエストのマージ] ダイアログで選択できます。管理者は、提供されるマージ戦略と、既定になるマージ戦略を構成できます。
プル リクエストのマージ時にマージ戦略を変更するには、使用するマージ戦略をクリックして ([マージ] ボタンの横) 新しいものを選択します。
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.