Manually closing bitbucket's pull request Manually closing bitbucket's pull request git git

Manually closing bitbucket's pull request


As I understand it, there are two ways to close a Bitbucket pull request as "Merged".

  1. Click the 'Merge' button. Bitbucket will merge your feature branchinto the destination branch. (Newer versions of Bitbucket allow you to choose between --no-ff and --squash strategies. Older versions implicitly use --no-ff.)
  2. Use git console commands (or other interface) to merge your featurebranch into your destination branch, then push both to origin.

The first option is definitely the easiest and most straightforward, but it does not work well with certain development workflows.

The key to getting the second option to work is that your feature branch must be on your destination branch. Bitbucket checks periodically for pull requests that have been merged manually and, when found, automatically marks those pull requests as Merged. Note: Atlassian does not advertise this behavior. I was not able to find any official documentation supporting this claim, but at least one other person out there has seen it work.

Based on the workflow you described, I'm guessing the person who reviewed and pushed your changes has a git history that looks something like this:

*   ddddddd (origin/master, master) new feature, squashed| * ccccccc (origin/new_feature, new_feature) new feature part C| * bbbbbbb new feature part B| * aaaaaaa new feature part A|/o

In this instance, the simplest way to have Bitbucket automatically close out the pull request would be:

git branch --force new_feature dddddddgit push --force origin new_feature

This also works for feature branches that have been rebased.

WARNING! Keep these facts in mind:

  • Not all workflows allow force pushes of this sort.
  • Bitbucket automatically updates the commits shown by a pull requestwhenever its feature branch changes. Depending on the order in whichyou push your branches, this can result in an empty commit listing.(More on this below.)
  • When a pull request is closed, any commit history and diffinformation are frozen.

When you push your destination branch to origin before you push your feature branch, Bitbucket first looks for any commits on the newly pushed feature branch that aren't on the destination branch. Since the new feature branch is an ancestor of the destination branch, the result is empty set. Bitbucket therefore removes all commits from the commits tab of the pull request, which now reads, "There are no changes." Then, since the feature branch is in the destination branch's history, Bitbucket closes the pull request, freezing the empty commits tab as so:

There are no changes.

Curiously, the diff remains intact in this case.

If none of the above merging options work for you, your only remaining options are:

  • Decline the pull request.
  • Consider changing your workflow to something Bitbucket more easilysupports.
  • Float a feature request with Bitbucket/Atlassian.

See also documentation for git-branch and git-push.


UPDATE

As of 31 January 2017 a feature was implemented to address the inability to close PRs manually.

Please refer to (and upvote!) the answer by @BenAmos for details.


Original Answer

(kept for historical purposes)

You are not missing anything. Bitbucket does not automatically close your pull request when it has been merged.

You have to manually close the pull request yourself by selecting the "Decline" option.

enter image description here


BitBucket Server 4.5.1 modified how remote merges are classified in the pull request (i.e. declined or merged).

@BenAmos 's answer above works well, but if you push the merge commit to the destination branch BEFORE force pushing onto the feature branch, BitBucket will automatically close the pull request and classify it as 'declined'.

However, if you instead force push onto the feature branch BEFORE pushing the merge commit to the destination branch, BitBucket will automatically close the pull request and classify it as 'merged'.

From Atlassian:"A pull request will now be declined after a push if: there are no commits on the from-branch that are not also on the to-branch AND the to-branch has not been updated in the same push"

Reference: https://jira.atlassian.com/browse/BSERV-4219?src=confmacro&_ga=1.138319284.547646488.1457297841