git 手动关闭 bitbucket 的拉取请求

Manually closing bitbucket's pull request

提问by user2046612

My question

我的问题

I do things like that:

我做这样的事情：

git clone
git checkout -b new_feature
< work and commit >
git rebase master
< work and commit >
< finish working >
git rebase master
git push origin new_feature
< I create pull request via bitbucket's web interface >

Someone who reviewing the changes is doing:

更改的人正在做：

git pull
git checkout master
git merge --squash new_feature
git push origin master

I was hoping this will close the pull request as accepted but it did not, what am I missing?

我希望这会关闭接受的拉取请求，但它没有，我错过了什么？

Some background information

一些背景资料

I read lots of bitbucket's documentation "working with pull requests" but this is still not clear for me.

我阅读了很多 bitbucket 的文档“处理拉取请求”，但这对我来说仍然不清楚。

I can see all my commits from new_featurebranch have been applied to the masterbranch (via git merge --squash) and I can see which files have changed, but now when I press "merge" on a bitbucket's pull-request interface I have another commit in master which is merge and this does not change any files (all the changes were already applied by previous git merge --squash) but just brings all those commits history into the master which is not what I wanted.

我可以看到来自new_feature分支的所有提交都已应用于master分支（通过git merge --squash），并且可以看到哪些文件已更改，但是现在当我在 bitbucket 的拉取请求界面上按“合并”时，我在 master 中有另一个提交，即合并并且这不会更改任何文件（所有更改都已由前一个应用git merge --squash），但只是将所有这些提交历史记录到主服务器中，这不是我想要的。

Via: https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests

通过：https: //confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests

Manually pulling requests to your local system

Sometimes it is a good idea to use a workflow where you test a changeset on your local system before accepting a pull request. You can do this with any pull request. The typical workflow is this: Receive a pull request in Bitbucket. Update your local repository with the incoming changeset. Investigate and/or test the change set. If you the change set is good, you merge it into your local repository. You may have to resolve some conflicts. Then, you push the local repository back to Bitbucket. Back on Bitbucket, the pull request is marked as accepted in the Pull requests tab. If you don't like the change request, you discard the changes locally and reject the pull request on Bitbucket. Ideas?

手动将请求拉到本地系统

有时，在接受拉取请求之前使用在本地系统上测试变更集的工作流是个好主意。您可以使用任何拉取请求执行此操作。典型的工作流程是这样的：在 Bitbucket 中接收拉取请求。使用传入的变更集更新您的本地存储库。调查和/或测试变更集。如果您的更改集是好的，则将其合并到您的本地存储库中。您可能需要解决一些冲突。然后，将本地存储库推送回 Bitbucket。回到 Bitbucket，拉取请求在拉取请求选项卡中被标记为已接受。如果您不喜欢更改请求，则在本地丢弃更改并拒绝 Bitbucket 上的拉取请求。想法？

回答by Ben Amos

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

据我了解，有两种方法可以将 Bitbucket 拉取请求关闭为“合并”。

1. Click the 'Merge' button. Bitbucket will merge your feature branch into 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 feature branch into your destination branch, then push both to origin.

1. 单击“合并”按钮。Bitbucket 会将您的功能分支合并到目标分支中。（较新版本的 Bitbucket 允许您在 --no-ff 和 --squash 策略之间进行选择。旧版本隐式使用 --no-ff。）
2. 使用 git 控制台命令（或其他界面）将您的功能分支合并到您的目标分支，然后将它们推送到源。

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.

使第二个选项起作用的关键是您的功能分支必须在目标分支上。Bitbucket 定期检查手动合并的拉取请求，并在找到时自动将这些拉取请求标记为已合并。注意：Atlassian 不会宣传此行为。我找不到任何支持此声明的官方文件，但至少有其他人已经看到它起作用了。

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:

根据您描述的工作流程，我猜并推送您的更改的人的 git 历史记录如下所示：

*   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:

在这种情况下，让 Bitbucket 自动关闭拉取请求的最简单方法是：

git branch --force new_feature ddddddd
git 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 commitsshown by a pull request whenever its feature branch changes. Depending on the order in which you 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 diff information are frozen.

• 并非所有工作流都允许这种强制推送。
• 每当其功能分支发生变化时，Bitbucket 会自动更新拉取请求显示的提交。根据您推送分支的顺序，这可能会导致一个空的提交列表。（更多关于这个下面。）
• 当拉取请求关闭时，任何提交历史和差异信息都会被冻结。

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:

当您在推送功能分支之前将目标分支推送到源时，Bitbucket 首先会在新推送的功能分支上查找不在目标分支上的任何提交。由于新功能分支是目标分支的祖先，因此结果为空集。因此，Bitbucket 从拉取请求的提交选项卡中删除所有提交，现在显示为“没有更改”。然后，由于功能分支在目标分支的历史记录中，Bitbucket 关闭拉取请求，冻结空的提交选项卡，如下所示：

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 easily supports.
• Float a feature requestwith Bitbucket/Atlassian.

• 拒绝拉取请求。
• 考虑将您的工作流程更改为 Bitbucket 更容易支持的内容。
• 使用 Bitbucket/Atlassian浮动功能请求。

See also documentation for git-branchand git-push.

另请参阅git-branch和git-push 的文档。

回答by Potherca

UPDATE

更新

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

截至 2017 年 1 月 31 日，已实施一项功能以解决无法手动关闭 PR 的问题。

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

有关详细信息，请参阅（并投票！）@BenAmos 的回答。

---

---

Original Answer

原答案

^{(kept for historical purposes)}

^{（保留用于历史目的）}

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

你没有错过任何东西。合并后，Bitbucket 不会自动关闭您的拉取请求。

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

您必须通过选择“拒绝”选项手动关闭拉取请求。

回答by McGeggles

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

BitBucket Server 4.5.1 修改了拉取请求中远程合并的分类方式（即拒绝或合并）。

@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'.

@BenAmos 上面的回答效果很好，但是如果您在强制推送到功能分支之前将合并提交推送到目标分支，BitBucket 将自动关闭拉取请求并将其归类为“已拒绝”。

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'.

但是，如果您在将合并提交推送到目标分支之前强制推送到功能分支，BitBucket 将自动关闭拉取请求并将其归类为“已合并”。

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"

来自 Atlassian：“在推送后，拉取请求现在将被拒绝，如果：从分支上没有提交不在到分支上的提交，并且到分支没有在同一个推送中更新”

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

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

回答by Denis Malyshev

I guess, bitbucket does not recognize your PR as merged, because git merge --squashproduces a completely newcommit. In our company we also tried git merge --squashfeature branches when merged them into main branch, but gave it up because pull-requests merged this way kept hanging around, and later we needed to "Decline" them or remove the related remote feature branches.

我想，bitbucket 不会将您的 PR 识别为已合并，因为git merge --squash会产生一个全新的提交。在我们公司，我们也尝试了将git merge --squash特性分支合并到主分支时，但放弃了，因为以这种方式合并的 pull-request 一直在徘徊，后来我们需要“拒绝”它们或删除相关的远程特性分支。

What we are currently doing is squashing all feature branch commits into one and force pushing it to a remote feature branch. After that, the person responsible for merging into master just need to click "Merge" on the bitbucket's pull request page and that is it, the PR is marked "Merged" and all changes introduced in the feature branch are squashed into a one neat commit.

我们目前正在做的是将所有功能分支提交压缩为一个，并强制将其推送到远程功能分支。之后，负责合并到master的人只需要在bitbucket的pull request页面点击“Merge”，就是这样，PR被标记为“Merged”，特性分支中引入的所有更改都被压缩成一个整洁的提交.