引入请求手动合并后衍合不显示在Github上

为合并为了保持一个线性的历史，我用下面的方法来合并，而不是依赖于GitHub的合并功能的变化：引入请求手动合并后衍合不显示在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 PRs合并和关闭的请求？

来源

2015-01-02 mandark

我认为这是rebase，而不是冲突，导致github无法确定拉请求合并。 – Gordon

@戈登你说得对。重新绑定分支会创建一组不同的提交，与原始提交集无关，而github无法检测到新提交与相同的拉取请求有关。 – mandark

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

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

来源

2015-06-26 07:37:29 mandark

由于该功能是重新设计的，因此其提交历史记录会完全抵消。这基本上是一个新的分支。

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

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

一旦GitHub上获得新主人，拉请求将被关闭。

来源

2015-01-02 15:11:18 onlythefinestwilldo

就像你说的那样，这需要写入权限，这是不同的场景。另外，可以更改本地历史记录，但不建议更改公共历史记录，尤其是在可能影响另一个用户的情况下，该用户在此情况下将成为拉取请求的创建者。 – mandark

引入请求手动合并后衍合不显示在Github上

回答

相关问题