在 rebase 后手动合并的拉取请求在 Github 上不显示为已合并答案

【问题标题】：Pull requests merged manually after a rebase don't show as merged on Github在 rebase 后手动合并的拉取请求在 Github 上不显示为已合并
【发布时间】：2015-02-28 16:18:10
【问题描述】：

为了保持线性历史，我使用以下方法来合并更改，而不是依赖 github 的合并功能：

git checkout -b feature_x user/feature_x
git rebase master                           
git checkout master
git merge --no-ff feature_x
git push origin master                       # On Github: PR gets merged and closed
git branch -D feature_x

上面的工作非常好，但在我必须手动解决冲突的情况下，PR 不会在 Github 上自动显示为合并，我必须手动关闭 PR。

有没有更好的方法来合并自动显示 Github PR 合并和关闭的拉取请求？

【问题讨论】：

我认为是变基而不是冲突导致 github 无法识别拉取请求已合并。
@Gordon 你是对的。重新定位分支会创建与原始提交集无关的不同提交集，并且 github 无法检测到新提交与相同的拉取请求相关。

标签： git github merge command-line-interface rebase

【解决方案1】：

正如onlythefinestwilldo 正确指出的那样，一旦分支被重新定位，它就会包含一组不同的提交，这意味着原始拉取请求不会受到影响。

为了克服这个问题，我们改变了我们的流程：现在，我们在将更改合并到 master 时不会 rebase 分支。如果无法合并更改，则要求拉取请求的创建者重新设置其分支并更新拉取请求。虽然不方便，但这是确保拉取请求在合并时自动关闭的唯一方法。

【讨论】：

【解决方案2】：

由于该功能被重新定位，它的提交历史被完全抵消。那时它基本上是一个新分支。

您可以强制推送重新定位的功能分支，覆盖拉取请求（假设您是维护者并且您具有对 fork 的写入权限）。

$ git push -f [feature] [remote] [feature]

一旦 GitHub 获得新的 master，pull request 将被关闭。

【讨论】：

就像你说的，这需要对 fork 的写访问，这是一个不同的场景。此外，更改本地历史记录是可以的，但不建议更改公共历史记录，特别是当它可以影响另一个用户时，在这种情况下将是拉取请求的创建者。