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



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

  1. 我在几分钟内收到两个Pull请求
  2. 两个Pull请求看起来都很棒,并且与master分支没有冲突。我想把它们合并成master
  3. 我合并了第一个Pull Request,效果很好
  4. 我回到第二个Pull Request,现在有冲突

我想做的是为贡献者解决冲突。冲突往往很小,不值得要求出资人进行重新定基的过程。问题是,我不能总是在Github在线编辑器中完成,如果我按照Github制定的步骤在终端中进行更改,我最终会创建自己的分支,我自己的Pull Request,而贡献者的Pull Request最终会被随意关闭!

我知道从技术上讲,代码最终是一样的,但关闭Pull Request似乎很糟糕,恰好是我选择在第二秒内合并的那个请求。有更好的方法吗?我是不是误解了什么?

我想我想问的问题是;我是否可以在来自我的存储库的分叉上进行更改并推送到分支,即使它不是我的分叉"这样,"拉取请求"将自动更新我创建的解析,并且我可以拉入更改。

I在活跃的repos上也遇到过这种情况(尤其是在Hacktoberfest期间)。

直接回答

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

事实上,这是您的存储库的分支,只是为了提供信息,因为我可以通过克隆您的项目并推送到我自己的远程来轻松创建分支。

Meta

你不想"麻烦"贡献者来解决这些冲突,这很好,但他们真的应该这样做。这就是公关模式的运作方式。

现在,你可以:

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

但这似乎会"剥夺"贡献者的部分经验,以及合并的PR。

对于维护人员来说,更大的问题是这不会扩展。如果你有两个只有空白空间的小PR冲突,这很好,但很快就会变得难以控制。所以不要养成这样做的习惯。唯一的例外是您不能等待合并的紧急/中断/安全修复。

最新更新