将两个单独的要素分支合并到同一个主分支中 [英] Merging two separate feature branches into the same main branch

问题描述

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

We are working towards a release: 2 remote feature branches: F2 and F3

我们如何处理F3来创建发行版?

How do we deal with F3 to create the release?

• 建议1 :将F3完全合并到开发中.
• 建议2 :首先将开发合并到F3中(包括F2更改)，然后将合并到开发中.

• Proposal 1: Simply merge F3 into development.
• Proposal 2: First merge development into F3 (including the F2 changes), then merge into development.

这两种方法之间的实际区别是什么?有客观原因偏爱另一个吗?

蓝色=主节点=发布分支红色=开发分支绿色=功能分支

Blue = Master = Release Branch Red = Development branch Green = Feature branches

推荐答案

结果是相同的，即使在'D'之前的最后2次提交中也没有什么区别.

The outcome is the same, not even a bit differnence on the last 2 commit before 'D'.

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

But our current workflow is the second one, but it's not a git related choice, it's because we have a lot of automated tests, and more than one release, so we like to run them everywhere where we need to merge the changes.

因此，基本上，由于在"D"，"f3 head"之间没有来源上的差异，因此它更像是一种技术选择.

So basically, since there are no differences in the sources, between 'D', 'f3 head', it's more like a technical choice.

如果选择第二种方法，则有机会在f2 merge，f3 merge和d之前运行测试，但是仅当使用要素分支(f2，f3)时才有意义，因为两者之间可能存在时差合并，在此期间可能会有其他提交合并到您的开发分支中.这样，您可以在两个分支的"f3合并"上进行测试，然后在合并回具有所有固定特征的d时进行测试.但是同样，只有在f2 merge和d之间存在提交时，这才有意义.

If you choose the second way, you have the opportunity to run tests before f2 merge, f3 merge , and d, but it's only make sense if you use feature branches(f2, f3), since there can be time differences between the merges, and during that time there can be other commits merged into your dev branche(s). In this way, you can test on 'f3 merge' for the two branches, then on merge back to d with all your finised features. But again, it only make sense, if there are commits between f2 merge and d.

如果您使用dev分支进行迭代(在这种情况下，f2和f3应该只是为了隔离您的开发，就像大多数本地分支一样)，那么您应该将整个迭代中的合并合并并一起测试，因此无需测试3个不同的点.

If you use dev branches for the iteration(in this case f2, and f3 should be there just to isolating your development, like mostly local branches ), then, your merges from your entire iteration should be merged in and tested together, so there is no need to test on 3 different points.

因此，基本上，第二个原因是因为f3需要f2中的功能，并且您想要在合并回开发人员之前，或者如果您有多个版本，则要对它们进行测试.因此，例如，并非来自f2的所有提交都将在您的dev分支上，但是您仍然需要一起测试f2和f3.

So basically, the reason behind the second one, is for examle that f3 need the features from f2, and you want to test them together before merging back, to your dev, or if you have multiple releases. So for example not all commits from f2 will be on your dev branch, but you still need to test f2 and f3 together.

这是一个棘手的问题，有很多需要考虑的地方.

It's a tricky question, there is a lot to consider.

但是，好消息是，即使您以后改变主意，或同时使用这两种策略，git都不会有问题，因此请尝试一下，然后在五个月内重新评估.

But the good news, is even if you change your mind later, or use both strategies git will have no problem with it, so just try them borh, and reevaluate in a fev months.

这篇关于将两个单独的要素分支合并到同一个主分支中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！