将两个单独的要素分支合并到同一主分支

Question

我们正在努力发布：2个远程功能分支：F2和F3

我们如何处理F3来创建发布？

• 提案1 ：简单地将 F3合并到开发中。
• 提案2 ：首先合并开发到F3（包括F2更改），然后合并进入开发。

这两种方法有什么实际区别？有客观的理由偏爱一个吗？

Blue = Master = Release Branch 红色=开发分支 绿色=功能分支

Answer 1

结果是相同的，在'D'之前的最后2次提交中甚至没有一点差异。

但我们目前的工作流程是第二个，但它不是git相关的选择， 这是因为我们有很多自动化测试和多个版本，因此我们希望在需要合并更改的任何地方运行它们。

所以基本上，由于来源之间没有差异，在'D'，'f3 head'之间，它更像是一种技术选择。

如果你选择第二种方式，你有机会在f2合并，f3合并和d之前运行测试，但只有你使用特征分支（f2，f3）才有意义，因为它们之间可能存在时间差异合并，在此期间可以将其他提交合并到您的dev分支中。通过这种方式，您可以测试两个分支的'f3 merge'，然后使用所有已完成的功能合并回d。但同样，只有在f2 merge和d之间有提交才有意义。

如果你使用dev分支进行迭代（在这种情况下是f2，而f3应该只是为了隔离你的开发，就像大多数本地分支一样），那么，你整个迭代的合并应该合并并一起测试，所以没有必要在3个不同的点上进行测试。

所以基本上，第二个问题背后的原因是，f3需要f2中的功能，并且你想在合并之前测试它们，你的开发者，或者如果你有多个版本。因此，例如，并非所有来自f2的提交都将在您的dev分支上，但您仍需要一起测试f2和f3。

这是一个棘手的问题，需要考虑很多。

但好消息是，即使你以后改变主意，或者同时使用这两种策略，git也不会有问题，所以只需要尝试它们，并在几个月内重新评估。