Question

我们有一个发布模型，为了简单起见，我们会说每月1个。所以，我们通常会去：

Jan -> trunk
       trunk -> Feb
       trunk <- Feb
Mar <- trunk 
Mar -> trunk
       etc

我们正在考虑放弃主干，给出更像的模型：

trunk -> Jan
  Jan -> Feb
  Feb -> Mar
  Mar -> Apr
  etc

我们永远不会合并回主干。虽然工作在Feb分支上进行，但任何紧急修复都发生在Jan分支上，并且合并到2月的代码库。

这似乎提供了很多好处，包括远远少于合并。有人发现明显的缺陷/缺点，理想情况是经验吗？

Answer 1

这似乎提供了充足的好处

无法看到任何，但至少可以检测到一次头痛

包括远，更少的合并

错误。两个工作流中的修补程序的前向移植具有相同数量的合并

<强>恢复：

Subversion中的所有URL都具有相同的权限，使用路径/主干作为主线只是方便，您可以忽略。但是不要忘记侧边 - 而不是单个svn up到比当前月份修订更早的版本svn switch & svn up（并且在切换之前识别此修订的URL - 也将日志添加到列表中）

Answer 2

似乎你分支太早，并试图放弃早期的分支，但却没有意识到它。

在正常的基于干线的工作流程中，只要“Jan”发布，您就会分支“Jan”。然后你继续在trunk上工作，释放“Feb”的分支作为“Feb”。换句话说：在主干模型中，您将分支推迟到发布点。当您发现自己合并除了功能分支或修补程序以外的任何内容时，工作流程都会中断。规划发布分支上的大量工作是错误的。树干和特征分支用于面包和黄油的工作;发布分支是为了紧急情况。

您的新模型很好，但您可以通过以下方式保持既定的命名约定：

 trunk
 trunk -> Jan   /* Release */
 trunk <- Jan   /* Hotfix */
 trunk -> Feb
 trunk -> Mar
 trunk -> Apr

请注意，这在拓扑上等同于无干线模型：

trunk                     Jan
 +----------- Jan          +------------   
 +------- Feb  |       Feb +--------   |
 +--- Mar  |   |       Mar +----   |   |
 |     |   |   |       Apr |   |   |   |
 |     |   |   |           |   |   |   |
trunk Mar Feb Jan         Apr Mar Feb Jan

但是，在无主干模型中，您不断重命名在主干模型中名为“trunk”的垂直路径。由于大多数时候每个人都在使用主干，因此命名会妨碍许多交换机，例如LazyBadger已经说过。

虽然svn switch的费用肯定不高，但遗忘svn switch的费用却是如此。在某些时候，当Mar是当前分支时，有人会在从假期返回后意外地在Apr上工作。然后，您必须检测该问题（QA），将代码合并到Apr并在Mar中还原。在trunk上进行常规工作时，问题不会发生，因为trunk始终是新工作的好点。

Answer 3

向其他读者回答我自己的问题：在几个月和几个版本之后，方法运行良好;我们希望所有实现的好处，没有出现任何缺点。团队中的共识是，它是一个更好的模型。

SVN分支模型的任何缺点：分支 - ＆gt;下一个分支，放弃后备箱？

3 个答案: