Get started with Bitbucket Cloud
New to Bitbucket Cloud? Check out our get started guides for new users.
Merge a pull request
When the desired number of reviewers have approved a pull request, you can merge the pull request if you have write (or admin) permission on the repository. If you've been touching the same code as someone else, you may have a merge conflict that you need to resolve locally. After you merge a pull request, you can revert the pull request to remove the merge commit from the repository.
Merge a pull request
Merging your changes is the final stage of the pull request process. To merge a pull request:
Select the Merge button.
(Optional) Update the Commit message with more details. Note: The size of the message is limited to 128KiB.
Select a Merge strategy from the dropdown menu. For more information on merge strategies, see the Merge strategies section below.
(Optional) If you're merging two branches in the same repository, you can select the Close source branch checkbox to remove the branch from the list of repository branches.
Select the Merge button.
Bitbucket will also mark any other pull requests that are composed only of commits from the branch you are merging as ‘merged’. For example, if another open pull request is a branch off the one you are merging, but has no additional commits, the other open pull request will also be marked as ‘merged’.
Merge checklist
To set up a merge checklist
You must be a repository administrator to add a merge checklist to a repository. For more details, see Suggest or require checks before a merge.
To configure and set up custom merge checks
You must be a Workspace admin to configure and set up custom merge checks. For details, see Set up and use custom merge checks.
As you're about to merge your pull request, you may see a Merge checklist. This checklist is a list of items that your administrator requests that you resolve before you merge your code. Any checklist items with a warning label are unresolved.
If your organization has a Premium plan, then the workspace admin can require that merge checks are resolved before the pull request can be merged.
If this checklist item has a warning label | Then your pull request |
|---|---|
At least {#} approvals | doesn't have that number of approvals |
At least {#} successful builds on last commit | doesn't have that number of successful builds for the most recent commit |
No failed builds on last commit | has failed builds on the most recent commit |
Resolved pull request tasks | has open pull request tasks |
Viewing your merge checks
As an administrator or a reviewer on a pull request, you can view the merge checks (required or otherwise) in the top merge check panel on the right sidebar to see what has and has not yet been completed prior to approving the pull request.
Merge strategies
Git merge strategies affect the way the Git history appears after merging a pull request. The type of strategy you choose to use depends on the workflow you've created for your workspace and how you use your repository.
Merge commit—Keeps all commits from your source branch and makes them part of the destination branch.
This option is the same as entering git merge --no-ff in the command line.Fast forward—Moves commits from the source branch to the destination branch (if the destination has no new commits).
This option is the same as entering git merge --ff-only in the command line.Rebase, 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.
Rebase, fast-forward (rebase + merge --ff-only): Commits from the source branch onto the target branch, creating a new non-merge commit for each incoming commit. Fast-forwards the target branch with the resulting commits. The PR branch is not modified by this operation.
Squash—Combines your commits when you merge the source branch into the destination branch.
This option is the same as entering git merge --squash in the command line.
Note: When you enter git merge --squash in the command line locally, the pull request will remain in the ‘open’ state after you push the changes to Bitbucket. This is because we use the commit graph to detect that changes were applied, and when ‘squash merge’ is used, we cannot detect that the pull request was merged or display an accurate diff. The pull request will now contain identical changes between the two branches, so the pull request will show no diff. However, you will be able to see the commit history of the pull request and view the individual commits.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.
While you can't undo a pull request, you can revert the merged commit from a pull request if necessary. Bitbucket takes two steps to revert a pull request: 1) Bitbucket creates a new branch with one commit that reverses the merged commit. 2) Bitbucket creates a new pull request for the branch and commit.
Revert a merged pull request
To revert a pull request:
From the pull request, click the Revert button in the top right.
(Optional) From the Revert pull request dialog, change the Branch name for the new branch you're about to create.
Click the Revert button. Once you click Revert, Bitbucket creates the new branch. Even if you cancel the pull request, the revert branch remains in the repository.
The Create a pull request page opens with the revert branch as the source. After you add your reviewers and make additional changes, click Create.
Was this helpful?
Still need help?
The Atlassian Community is here for you.