如何解决如何在GitHub中合并带有冲突的PR，而无需**首先将基础合并到头部相反？
在我与其他一些人合作的存储库之一中，我们使用拉取请求作为管理合并的一种方式，有时会遇到合并冲突（通常会发生这种情况）。麻烦之处：其他开发人员一直在使用GitHub Web界面进行实际的合并（除了仅创建PR外）。
根据GitHub文档：
警告：解决GitHub Enterprise上的合并冲突时 服务器，整个base branch 您的拉取请求中的合并到head branch中。使 确定您确实要提交到该分支。如果头分支是 存储库的默认分支，您将获得以下选项： 创建一个新分支以用作拉动的头分支 请求。如果头分支受到保护，您将无法合并 解决您的冲突，因此系统会提示您创建一个 新的总行。有关更多信息，请参见“ About protected branches”。
有时候这并不是我们想要的。这就是为什么。
例如，假设我们正在研究两个功能分支：
feature/123
feature/456
并且feature/123在staging中，但尚未准备好master。
我们想将feature/456合并到staging中，因此我们创建了PR，并且它存在合并冲突。
如果有人使用GitHub Web界面合并该PR，则实际发生的情况如下：
- GitHub将把
staging（已经包含来自feature/123的工作）合并到feature/456。 - 用户将解决冲突。
- GitHub将
feature/456合并为staging。
不幸的是，一旦feature/456准备好master，当有人执行合并时，feature/123中的代码更改（还没有准备好黄金时间）将随之而来。放入master。
我99％可以肯定，此行为背后的想法是GitHub希望您解决头分支而不是基础分支中的合并冲突，即feature/456而不是staging。
有没有办法让GitHub解决staging中的冲突？
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
