多个相关功能分支的工作流程

Question

假设我需要处理两个功能：FEATURE1和FEATURE2。 FEATURE2是相关的，应该在FEATURE1之上开发。

我从FEATURE1创建了MASTER。通常最好的方案是完成FEATURE1，合并回MASTER，然后直接从FEATURE2分支MASTER。

但是在这种情况下有一些限制：

• FEATURE1差不多完成了，但无法立即合并到MASTER。
• FEATURE2的工作应从FEATURE1停止的地方开始。
• FEATURE1和FEATURE2应该分别合并到MASTER （他们应该单独测试/验证 ）。< / LI>
• FEATURE1可能会有一些额外的更改，然后才能合并到MASTER（ 上FEATURE2的工作已经开始了。）

因此，对于这种情况，问题是：

• 是否从FEATURE2分支FEATURE1（如图中所示）是一个不错的选择？
• 在将FEATURE1和FEATURE2（单独）合并回MASTER时，应该采取哪些措施来尽量减少可能发生的冲突？

Answer 1

从FEATURE1分支是正确的选择，并且不应该有太多麻烦。

假设FEATURE1开发将在分支到FEATURE2之后继续，您可以单独合并这两个，git会处理它。

当然，如果FEATURE1和FEATURE2同时操作相同文件的同一行，您将会按照惯例进行合并冲突，并且在继续之前您需要解决它们与你合并。但是，如果他们没有触及相同的行，则不会发生任何合并冲突，并且可以随意将它们合并。

如果FEATURE1分支在FEATURE2分支后没有任何进一步的提交，并且FEATURE2被合并回主服务器，则您将无法单独合并FEATURE1（作为{{ 1}}已包含FEATURE2）中的所有提交。

Answer 2

我会根据您当前feature2的状态分支feature1。

在feature1开发新API（案例1）或feature1已准备好投放并已合并到master（案例2）后，您应该重新定义{{1在feature2（案例1）或feature1（案例2）。

案例1，master是新的API或更正：

Q

案例2，master A B C D \ feature1 M N P Q \ feature2 X' Y' Z' 是M和feature1的合并提交：

master