我是从同一个分支合并还是从合并中合并？

Question

一种最佳实践问题:直接从源合并到其他分支更好，还是可以从合并中合并？

使用Subversion进行源代码管理。

场景

• 分支A进行并提交了更改。
• 分支B和中继都需要更新。

案例1

从A合并到B，再从A合并到主干。

或

案例2

从A合并到B，然后从B合并到主干。

我可能还缺少了一个案例3，您可以同时合并到B和T中继(不确定这是否取决于所使用的源代码管理？)。

请注意，可能有许多需要合并的分支，因此您可以“级联”合并(从A到B到C到D.)。

Answer 1

作为序言，我强烈建议阅读斯蒂芬·万斯的“先进的单片机分支策略”。这个答案很大程度上是基于那篇论文中建立的模型。

在版本控制系统中正确地分支和合并的一个关键特性是保持分支的角色一致和独立。不要让您的维护合并到您的主线，也不要让您的功能流到维护。

分支的基本角色是主线、开发、维护、积累和包装。虽然有时可以将它们结合在一起(例如，简单的‘主干一个开发人员设置中的所有东西’)，但是当在组和更复杂的环境中工作时，通常需要明确的角色分离。

你有两个特征分支。A和B.每个特性分支都应该从主线分支。同样，每个错误修复都应该从主线中分支。

主要编程(分支的原因)尚未完成，但错误修复需要跨多个分支和主干复制。

在这种情况下，特性分支A还包含一个bug修复程序，分支A的一部分需要通过系统进行合并。

最佳实践应该是从主线分支，进行维护(bug修复)并将其合并到主线中，然后根据需要将更改从主线提取到需要它的各个分支。

我将假设主线作为“只工作代码”的策略。我们不应该破坏主线的构建。同样，主线中的非工作代码意味着从该点开始的任何分支都会中断。

要解决这里的问题，最好的方法是创建另一个分支--积累分支。这样，在验证累积分支中的bug修复时，所有从主线完成的分支都不会被破坏。为此，请执行以下操作：

1. 分支主线到累加分支
2. 将bug修复从分支A合并到累积分支
3. 将累积分支合并回主
4. 将主线中的修复程序传播回其他分支。

另一个分支的关键实际上是创建一个只包含bug修复的维护分支，然后从那里开始。这使您可以确保正确地完成分支，而不中断主线，并进行任何额外的调整，以确保bug修复不会破坏任何其他内容。

Answer 2

我认为这完全取决于分支机构的结构。

1.分支A和B是独立的

branch A      +---------+-------------
             /           \ merge 1
trunk ------+--+----------+--+--------
                \             \ merge 2
branch B         +-------------+------

正如你在这里看到的，我将从A合并到主干，然后从主干合并到B。

2. A分支是B分支

的一个分支

trunk ------+------------------+-----
             \                / merge 2
branch B      +--+--------+--+-------
                  \      / merge 1
branch A           +----+------------

在这种情况下，我将合并从分支A到分支B，然后合并分支B到主干。

3. B分支是A分支

的一个分支

trunk ------+------------------+-----
             \                / merge 2
branch A      +--+--------+--+-------
                  \        \ merge 1
branch B           +--------+--------

在最后一种情况下，我将从分支A合并到分支B，然后将分支A合并到主干。注意:在这种情况下，顺序并不重要，从分支A合并到主干，然后从分支A合并到分支B将产生同样的效果。

我想我的想法的关键总是合并到父母或合并到孩子身上，避免合并不相关的或间接的祖先/后代分支。