3

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

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

我们正在考虑放弃主干，给出一个更像：

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

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

这似乎提供了很多好处，包括少得多的合并。任何人都发现了明显的缺陷/缺点，最好是从经验中发现？

4

3 回答 3

5

这似乎提供了很多好处

看不到任何东西，但可以检测到至少一种头痛

包括少得多的合并

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

简历：

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

于 2013-02-13T12:46:32.363 回答
1

似乎您的分支太早了，并且正试图放弃那个早期的分支，但没有意识到这一点。

在正常的基于主干的工作流程中，一旦“Jan”发布，您就会分支“Jan”。然后你继续在主干上工作，“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

但是，在无主干模型中，您会不断地重命名主干模型中名为“主干”的垂直路径。由于每个人大部分时间都在使用主干，因此命名会通过很多开关阻碍您，就像 LazyBadger 已经说过的那样。

虽然一个的成本svn switch肯定不高，但一个被遗忘的成本svn switch却是。在某些时候，有人会在Mar假期回来后不小心Apr在当前的分支上工作。然后您必须检测该问题 (QA)，将代码合并Apr到Mar. 当通常的工作完成后trunk，问题就不会发生，因为trunk对于新工作来说总是一个好点。

于 2013-02-13T13:28:18.493 回答
0

为其他读者回答我自己的问题：方法在几个月和几个版本后运行良好；我们希望所有的好处都实现了，没有出现任何缺点。团队一致认为这是一个更好的模型。

于 2013-10-17T09:49:35.383 回答