合并到下一个分支时如何解决基于分支主控的冲突补丁答案

【问题标题】：How to resolve conflicting patches based on branch master when merged to branch next合并到下一个分支时如何解决基于分支主控的冲突补丁
【发布时间】：2017-08-17 17:09:11
【问题描述】：

试图从建立在集成分支 master、maint、next 和 pu 之上的手册页 gitworkflows(7) 掌握 Git 工作流程。我不明白如何解决可能出现的合并冲突，例如维护者尝试将来自不同贡献者的补丁合并到分支 next 中，如果这些补丁基于分支 master 并且维护者没有它们目前已晋升为master。

有人知道我上面的问题的答案吗？

【问题讨论】：

这是特定项目的分支模式吗？如果是这样，还有哪些其他规则适用于那里？维护者是否可以要求贡献者将他们的贡献基于next 分支而不是master 并要求他们重新基于更新的next 以防合并冲突（或与更新的next 合并并自行解决合并冲突）？
这是手册页 gitworkflows(7) 中描述的分支模式，并且似乎是 Git 项目本身实践的一种。

标签： git merge patch git-workflow

【解决方案1】：

这实际上是在手册页本身上回答的，在Merge workflow 部分的末尾：

有时，维护者在尝试合并时可能会遇到合并冲突从下游拉取更改。 在这种情况下，他可以要求下游自己进行合并并解决冲突（也许他们会知道如何解决它们）。这是罕见的情况之一下游应该从上游合并。

（强调我的，常规强调他们的）

【讨论】：