从单独的分支解决 Github 上的拉取请求合并冲突的正确方法

Question

我目前正在维护我的第一个开源项目，并且一直遇到相同的情况。

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

我想做的是为贡献者解决冲突。冲突通常很小，不值得让贡献者经历变基的过程。问题是，我不能总是在 Github online editor 和 if I follow the steps laid out by Github 中进行更改以在终端中进行更改，我最终创建了自己的分支，我自己的 Pull Request，而贡献者的 Pull Request 最终变得毫不客气关门了！

我知道从技术上讲，代码最终是相同的，但是关闭恰好是我第二次选择合并的拉取请求似乎很笨拙。有一个更好的方法吗？我是不是误会了什么？

我想我想问的问题是，“我可以进行更改并推送到来自我的存储库的 fork 上的分支，即使它不是我的 fork？”这样一来，Pull Request 将自动更新为我创建的分辨率，我可以拉入更改。

Answer 1

我也在活跃的 repos 中遇到过这种情况（尤其是在 Hacktoberfest 期间）。

直接回答

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

作为你的存储库的一个分支的事实仅出于提供信息的目的进行跟踪，因为我可以通过克隆你的项目并推送到我自己的远程来轻松创建一个分支。

元

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

现在，你可以：

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

但这似乎会“剥夺”部分体验的贡献者以及合并的 PR。

对于维护者来说，更大的问题是这无法扩展。如果您有两个只有空白冲突的小型 PR，这很好，但它很快就会变得难以管理。所以不要养成这样做的习惯。唯一的例外是您不能等待合并的紧急/破坏/安全修复。