26

我的问题

我做这样的事情：

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 的拉取请求界面上按“合并”时，我在 master 中有另一个提交，即合并并且这不会更改任何文件（所有更改都已由 previous 应用git merge --squash），而只是将所有这些提交历史记录带入 master，这不是我想要的。

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

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

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

4

4 回答 4

18

据我了解，有两种方法可以将 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都会自动更新拉取请求显示的提交。根据推送分支的顺序，这可能会导致提交列表为空。（更多内容如下。）
  • 当拉取请求关闭时，任何提交历史记录和差异信息都会被冻结。

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

没有变化。

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

如果上述合并选项都不适合您，那么您唯一剩下的选项是：

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

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

于 2015-12-16T23:04:18.990 回答
16

更新

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

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

原始答案

（保留用于历史目的）

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

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

在此处输入图像描述

于 2014-02-07T10:32:58.640 回答
1

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

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

于 2017-04-14T10:26:27.260 回答
1

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

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

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

来自 Atlassian：“如果出现以下情况，则推送请求现在将被拒绝：从分支上没有提交也不在到分支上，并且在同一推送中未更新到分支”

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

于 2016-11-02T13:41:41.867 回答