从单独的fork解决Github上的pull请求合并冲突的正确方法

Question

我目前正在维护我的第一个开源项目，并且我一直在运行相同的场景。

1. 我在几分钟内得到两个Pull请求
2. 两个Pull请求看起来都很棒，并且不会与主分支发生冲突。我想将它们合并为主。
3. 我合并了第一个Pull Request，效果很好。
4. 我回到第二个Pull请求，现在有冲突

我想要做的是解决贡献者的冲突。冲突往往很小，不值得让贡献者经历变革过程。问题是，我不能总是在Github online editor和if I follow the steps laid out by Github中进行更改终端，我最终创建自己的分支，我自己的Pull请求和贡献者＆ ＃39;拉请求最终会被毫不客气地关闭！

我知道从技术上讲，代码最终是相同的，但是关闭Pull Request似乎非常糟糕，而Pull Request恰好是我选择合并的第二个。有一个更好的方法吗？我误解了什么吗？

我认为我试图提出的问题是，＆＃34;我是否可以进行更改并推送到来自我的存储库的分支上的分支，即使它不是我的分支？＆＃34 ;这样，Pull Request会根据我创建的分辨率自动更新，我可以提取更改。

Answer 1

我也在活跃的回购中遇到过这种情况（特别是在Hacktoberfest期间）。

直接回答

要回答您的问题，不，您只能推送到某人已明确授予您推送权限的存储库。

存储库的分支只是为了提供信息而被跟踪，因为我可以通过克隆项目并推送到我自己的遥控器来轻松创建分支。

元

很高兴你不要打扰＆＃34;打扰＆＃34;解决这些冲突的贡献者，但他们确实应该这样做。这就是PR模型的工作原理。

现在，您可以：

• 将他们的分支作为远程添加到您自己的工作副本
• 拉
• 修复冲突
• 推送您自己的分支
• 合并该分支

但这似乎是“抢劫”。部分经验的贡献者，以及合并的公关。

作为维护者，您面临的更大问题是这不会扩展。如果你有两个只有白色空间冲突的小PR，那很好，但很快变得无法管理。所以不要养成这样做的习惯。唯一的例外是您无法等待合并的紧急/破坏/安全修复。