手动关闭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的文档“使用拉取请求”，但这对我来说仍然不明确。

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

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

  

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

     

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

Answer 1

更新

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

请参阅（和upvote！）the answer by @BenAmos了解详情。

---

原始答案

^{（为历史目的保留）}

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

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

Answer 2

据我了解，有两种方法可以关闭Bitbucket拉取请求，因为＆＃34; Merged＆＃34;。

1. 点击＆＃39;合并＆＃39;按钮。 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请求的提交选项卡中删除所有提交，现在读取，＆＃34;没有更改。＆＃34;然后，由于功能分支位于目标分支的历史记录中，Bitbucket会关闭拉取请求，冻结空提交选项卡，如下所示：



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

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

• 拒绝拉取请求。
• 考虑将工作流程更轻松地更改为Bitbucket 支持。
• Float a feature request与Bitbucket / Atlassian。

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

Answer 3

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

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

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

来自Atlassian： ＆＃34;拉出请求现在将在推送后被拒绝if：在from-branch上没有提交也不在to-branch上并且to-branch没有在同一个push中更新＆＃34;

参考：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”，并且功能分支中引入的所有更改都被压缩成一个整齐的提交