手动关闭Bitbucket的拉取请求

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的“处理拉取请求”的文档，但对我来说仍然不清楚。

我可以看到我从new_feature分支中的所有提交都被应用到了master分支（通过git merge --squash），我也可以看到哪些文件已经更改。但现在当我在Bitbucket的拉取请求界面上按下“合并”按钮时，我会在主分支中有另一个合并提交，它不会更改任何文件（所有更改已经通过之前的git merge --squash应用了），只是将所有这些提交历史记录合并到主分支中，这不是我想要的。

来源：https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests

手动将请求拉到本地系统

有时候使用一种工作流，首先在本地测试changeset然后再接受拉取请求是一个好主意。你可以对任何拉取请求进行操作。典型的工作流程如下所示：接收一个Bitbucket中的拉取请求。使用传入的changeset更新您的本地存储库。检查和/或测试更改集。如果你认为更改集是好的，就将其合并到你的本地存储库中。你可能需要解决一些冲突。然后，将本地存储库推回到Bitbucket。在Bitbucket上，将在“拉取请求”选项卡中将拉取请求标记为已接受。如果您不喜欢更改请求，则在本地放弃更改并在Bitbucket上拒绝拉取请求。有什么想法吗？

- user2046612

---

请更新问题，说明您正在尝试做什么或理解什么。 - wberry

我也在尝试做同样的事情，但是也无法找到理想的解决方案。在本地对主分支进行合并压缩并将其推送到上游后，我不得不手动“合并”开放的PR，该PR具有0个变更集。 - Tri Nguyen

最理想的解决方案是不手动合并拉取请求，而是使用BitBucket UI。如果您必须在本地编辑PR，则没有理想的方法。 :-( - Potherca

有一个Bitbucket的功能请求开放 https://bitbucket.org/site/master/issue/8995/provide-the-option-to-use-git-merge-squash - Laoneo

Answer 1

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

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

第一种选项绝对是最简单和最直接的，但它与某些开发工作流程不兼容。

让第二个选项起作用的关键是您的功能分支必须在您的目标分支上。 Bitbucket定期检查已手动合并的拉取请求，并在找到时自动将这些拉取请求标记为已合并。注意：Atlassian没有宣传此行为。我无法找到任何官方文件支持这种说法，但至少还有另一个人看到过它的效果。 根据您描述的工作流程，我猜测审核并推送您的更改的人具有类似于以下内容的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 自动更新拉取请求中显示的提交。根据你推送分支的顺序，这可能会导致提交列表为空。（下文详细说明）
• 关闭拉取请求后，任何提交历史和差异信息都将被冻结。

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

有趣的是，在这种情况下，差异仍然保持不变。

如果以上合并选项都不适用于您，您唯一剩下的选择是：

• 拒绝拉取请求。
• 考虑更改您的工作流程以便更容易地支持Bitbucket。
• 向Bitbucket/Atlassian提出功能请求。

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

- Ben Amos

---

是的，这种情况也发生在我身上了，我通过控制台手动合并后，在Bitbucket上的拉取请求得到了更新。 - vaskort

对我来说也是一样的。合并和状态更改之间只有一点延迟。上面提供的“拒绝”解决方案是错误的！ - simon

Answer 2

更新

截至2017年1月31日，已经实现了一个功能来解决手动关闭PR的问题。

请参考（并点赞！）@BenAmos的答案获取详细信息。

---

原始回答

^{（仅供历史参考）}

您没有漏掉任何内容。当PR被合并时，Bitbucket不会自动关闭您的PR。

您需要通过选择“拒绝”选项手动关闭PR。

- Potherca

---

这会将公关标记为已拒绝，这是不正确的，因为实际上它已经合并了。 - Tri Nguyen

你说得对。我更新了我的答案，以更清晰地反映这一点。 - Potherca

@RobinGreen 你不行。拒绝是唯一的出路 :-( 我会重新措辞我的回答，让它更加清晰明了。 - Potherca

@Jeffpowrs 我看到越来越多的公司转向Gitlab，而不是Bitbucket。你的公司可能想要跟随这个趋势。否则，总有其他更加开发者友好的公司存在 :-) - Potherca

@BenAmos的回答更好，他说Bitbucket定期检查手动合并的拉取请求并将它们标记为已合并。这是在2015年12月16日发布的，因此可能在此答案之后添加了此功能，但我不知道是否属实。 - Ajoy Bhatia

Answer 3

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

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

然而，如果您在将合并提交推送到目标分支之前强制推送到特性分支，则BitBucket将自动关闭拉取请求并将其分类为“已合并”。

来自Atlassian： “如果：从分支上没有提交与to-branch上的提交不同，并且to-branch未在同一次推送中更新，则拉取请求现在将在推送后被拒绝。”

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

- McGeggles

Answer 4

我猜测，Bitbucket没有将您的PR识别为已合并，因为git merge --squash会生成一个全新的提交记录。在我们公司，当我们将功能分支合并到主分支时，我们也尝试了git merge --squash，但最终放弃了，因为以这种方式合并的拉取请求会一直挂起，后来我们需要“拒绝”它们或删除相关的远程功能分支。

我们目前正在做的是将所有功能分支提交记录压缩成一个，并将其强制推送到远程功能分支。之后，负责合并到主分支的人只需在Bitbucket的拉取请求页面上单击“合并”即可，PR将被标记为“已合并”，所有在功能分支中引入的更改都将被压缩成一个整洁的提交记录。

- ches151