从单独的分支解决 Github 上的拉取请求合并冲突的正确方法
The right way to resolve pull request merge conflicts on Github from separate fork
我目前正在维护我的第一个开源项目，并且 运行 处于相同的场景。
- 我在几分钟内收到了两个 Pull Request
- 两个 Pull Requests 看起来都很棒，并且不与 master 分支冲突。我想将它们合并到 master 中。
- 我合并了第一个 Pull Request，效果很好。
- 我回到第二个 Pull Request，现在有冲突
我想做的是为贡献者解决冲突。冲突通常很小，不值得要求贡献者完成变基过程。问题是，我不能总是在 Github online editor, and if I follow the steps laid out by Github 中在终端中进行更改，我最终创建了自己的分支，我自己的 Pull Request，而贡献者的 Pull Request 最终被毫不客气地关闭了！
我知道从技术上讲，代码最终是相同的，但关闭 Pull Request 似乎很糟糕，而 Pull Request 恰好是我选择在第二个合并的那个。有一个更好的方法吗？我是不是误会了什么？
我想我想问的问题是，"Can I make changes and push to a branch on a fork that came from my repository, even if it is not my fork?" 这样，Pull Request 会自动更新我创建的决议，我可以拉入更改。
我也在活跃的回购中遇到过这个问题（特别是在 Hacktoberfest 期间）。
直接回答
要回答您的问题，不，您只能推送到某人已明确授予您推送访问权限的存储库。
您的 存储库的分支这一事实仅出于提供信息的目的而被跟踪，因为我可以通过克隆您的项目并推送到我自己的远程来轻松创建一个分支.
元
很高兴你不想 "bother" 贡献者解决这些冲突，但他们确实应该这么做。这就是 PR 模型的工作原理。
现在，您可以：
- 将他们的分支作为远程添加到您自己的工作副本
- 拉
- 解决冲突
- 推送你自己的分支
- 合并那个分支
但这似乎 'rob' 部分体验的贡献者，以及合并的 PR。
作为维护者，您面临的更大问题是这无法扩展。如果你有两个只有 white-space-only 冲突的小 PR 没问题，但它很快就会变得难以管理。所以不要养成这样做的习惯。唯一的例外是 urgent/breaking/security 修复，您 不能等待 合并。
我目前正在维护我的第一个开源项目，并且 运行 处于相同的场景。
- 我在几分钟内收到了两个 Pull Request
- 两个 Pull Requests 看起来都很棒，并且不与 master 分支冲突。我想将它们合并到 master 中。
- 我合并了第一个 Pull Request，效果很好。
- 我回到第二个 Pull Request，现在有冲突
我想做的是为贡献者解决冲突。冲突通常很小，不值得要求贡献者完成变基过程。问题是，我不能总是在 Github online editor, and if I follow the steps laid out by Github 中在终端中进行更改，我最终创建了自己的分支，我自己的 Pull Request，而贡献者的 Pull Request 最终被毫不客气地关闭了！
我知道从技术上讲，代码最终是相同的，但关闭 Pull Request 似乎很糟糕，而 Pull Request 恰好是我选择在第二个合并的那个。有一个更好的方法吗？我是不是误会了什么？
我想我想问的问题是，"Can I make changes and push to a branch on a fork that came from my repository, even if it is not my fork?" 这样，Pull Request 会自动更新我创建的决议，我可以拉入更改。
我也在活跃的回购中遇到过这个问题（特别是在 Hacktoberfest 期间）。
直接回答
要回答您的问题，不，您只能推送到某人已明确授予您推送访问权限的存储库。
您的 存储库的分支这一事实仅出于提供信息的目的而被跟踪，因为我可以通过克隆您的项目并推送到我自己的远程来轻松创建一个分支.
元
很高兴你不想 "bother" 贡献者解决这些冲突，但他们确实应该这么做。这就是 PR 模型的工作原理。
现在，您可以：
- 将他们的分支作为远程添加到您自己的工作副本
- 拉
- 解决冲突
- 推送你自己的分支
- 合并那个分支
但这似乎 'rob' 部分体验的贡献者，以及合并的 PR。
作为维护者，您面临的更大问题是这无法扩展。如果你有两个只有 white-space-only 冲突的小 PR 没问题，但它很快就会变得难以管理。所以不要养成这样做的习惯。唯一的例外是 urgent/breaking/security 修复，您 不能等待 合并。