git - 手动关闭 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

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

一些背景信息

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

我可以看到我在 new_feature 分支中的所有提交都已应用到 master 分支(通过 git merge --squash)并且我可以看到哪些文件已更改，但是现在当我在 bitbucket 的 pull 请求界面上按“merge ”时，我在 master 中有另一个提交是 merge ，这不会更改任何文件(所有更改都已被之前的 应用git merge --squash) 但只是将所有这些提交历史记录带入 master，这不是我想要的。

通过: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?

Answer 1

据我所知，有两种方法可以将 Bitbucket pull 请求关闭为“已 merge ”。

1. 点击“merge ”按钮。 Bitbucket 将 merge 您的功能分支进入目标分支。 (较新版本的 Bitbucket 允许您在 --no-ff 和 --squash 策略之间进行选择。旧版本隐式使用 --no-ff。)
2. 使用 git 控制台命令(或其他界面) merge 您的功能分支到您的目标分支，然后将两者都推送到原点。

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

让第二个选项起作用的关键是你的功能分支必须在你的目标分支上。 Bitbucket 定期检查已手动 merge 的 pull 请求，并在找到时自动将这些 pull 请求标记为已 merge 。 注意: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 自动关闭 pull 请求的最简单方法是:

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

这也适用于已 rebase 的特性分支。

警告!请牢记以下事实:

• 并非所有工作流程都允许这种强制推送。
• 比特桶automatically updates the commits由 pull 请求显示每当它的功能分支发生变化时。取决于其中的顺序你推送你​​的分支，这可能会导致一个空的提交列表。(更多内容见下文。)
• 当 pull 请求关闭时，任何提交历史和差异信息被卡住。

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

奇怪的是，在这种情况下差异仍然完好无损。

如果以上 merge 选项都不适合您，您唯一剩下的选择是:

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

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