手动关闭bitbucket的pull请求

Question

我的问题

我做那样的事情：

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 >

审核更改的人正在执行以下操作：

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

我希望这会接受拉动请求，但是没有，我错过了什么？

一些背景资料

我阅读了很多bitbucket的文档“使用pull请求”，但这对我来说仍然不太清楚。

我可以看到来自new_feature分支的所有提交都已应用于master分支（通过git merge --squash），我可以看到哪些文件已更改，但现在当我在bitbucket的pull-request接口上按“merge”时，我在master中有另一个提交这是合并，这不会改变任何文件（所有的更改都已经被先前的git merge --squash应用）但只是将所有这些提交历史记录带入主人，这不是我想要的。

途经：https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests

手动将请求提取到本地系统

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

Answer 1

UPDATE

截至2017年1月31日，a feature was implemented解决了无法手动关闭PR的问题。

有关详细信息，请参阅（和upvote！）the answer by @BenAmos。

---

原始答案

（为历史目的而保留）

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

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

Answer 2

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

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

第一个选项绝对是最简单和最直接的选项，但它不适用于某些开发工作流程。

使第二个选项起作用的关键是您的功能分支必须位于目标分支上。 Bitbucket会定期检查已手动合并的拉取请求，并在找到时自动将这些拉取请求标记为合并。注意：Atlassian不会宣传此行为。我无法找到任何支持这种说法的官方文件，但至少还有一个人在那里has seen it work。

根据您描述的工作流程，我猜测审核并推送您的更改的人有一个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

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

git branch --force new_feature ddddddd
git push --force origin new_feature

这也适用于已重新定位的功能分支。

警告！记住这些事实：

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

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

奇怪的是，在这种情况下，差异保持完整。

如果上述合并选项均不适合您，则您唯一剩下的选项是：

• 拒绝拉取请求。
• 考虑将您的工作流程更改为Bitbucket更容易支持的内容。
• Float a feature request与Bitbucket / Atlassian。

另见git-branch和git-push的文档。

Answer 3

BitBucket Server 4.5.1修改了如何在拉取请求中对远程合并进行分类（即拒绝或合并）。

@BenAmos上面的答案很有效，但是如果你强行推送到功能分支，那么你将合并提交推送到目标分支，BitBucket将自动关闭拉取请求并将其归类为“已拒绝”。

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

来自Atlassian：“推送请求现在将在推送之后被拒绝：如果：from-branch上没有提交也不在to-branch上并且to-branch没有在同一个push中更新”

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

Answer 4

我猜，bitbucket不会将你的PR识别为合并，因为git merge --squash会产生一个全新的提交。在我们公司，我们也尝试将git merge --squash功能分支合并到主分支，但放弃了，因为牵引请求合并这种方式一直闲逛，后来我们需要“拒绝”它们或删除相关的远程功能分支。

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