重新基于分支后手动合并的拉取请求在 Github 上不会显示为已合并。

Question

为了保持线性历史，我使用以下方法合并更改，而不是依赖于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

以上方法完全有效，但是在需要手动解决冲突的情况下，该 Pull Request (PR) 不会自动显示为已合并在 Github 上，我必须手动关闭 PR。

有没有更好的方法来合并 Pull Request 并自动显示 Github 上的 PR 已合并并关闭？

- mandark

---

我认为是变基而不是冲突导致GitHub无法识别拉取请求已合并。 - Gordon

@Gordon 你说得对。将一个分支进行变基会创建一组不同的提交，这与原始的提交集没有任何关系，而且GitHub无法检测到新的提交与同一拉取请求相关。 - mandark

Answer 1

正如onlythefinestwilldo所指出的那样，一旦分支被变基，它就包含了一个不同的提交集合，这意味着原始拉取请求不会受到影响。

为了解决这个问题，我们已经改变了我们的流程：现在，在将更改合并到主分支时，我们不会变基分支。如果无法合并更改，则会要求拉取请求的创建者重新基于其分支并更新拉取请求。虽然有点麻烦，但这是确保拉取请求在合并时自动关闭的唯一方法。

- mandark

Answer 2

由于该功能已经被重新基于，其提交历史记录完全被抵消。此时基本上是一个新分支。

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

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

一旦GitHub获取了新的主分支，拉取请求将被关闭。

- onlythefinestwilldo

---

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