Question

我在一个项目中工作，其中一个发布版本在维护中，两个或多个版本同时开发。

这里出现了对行李箱需求的怀疑。

我已经阅读了阅读Bean和其他人的SVN书籍（带有Subversion的实用版本控制），然后建议使用以中继为中心的开发模式。我不知道在我的情况下这是否适用，以及是否存在具有多版本发布周期的其他项目成功使用其他模式。

为什么推荐使用以中继为中心的模式？版本分支越来越远离主干有什么问题吗？我这个架构与trunk的集成有什么意义吗？


                                          /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/--\
              /           /      /                          \
     /------------alpha--/------/---\                        \
    /                                \                        \
------------trunk--------------------(a)----------------------(b)------------------>

编辑：

当我说两个或更多开发版本时，我指的是具有增量级功能的软件版本。在上面的图形中：

alpha：功能A。
beta：功能A + B。
gamma：功能A + B + C.

意味着 all 分支的功能包含在以后的分支中（通过同步合并）。分支的稳定性水平不同（较旧的分支更稳定）和功能（年轻分支具有新功能）。

在TridenT回答后编辑2：

稳定版本的开发在trunk的分支中完成，然后在稳定时合并回trunk，因此trunk包含所有稳定的更改，最后是更稳定的软件版本。

我现在正在问这个问题，因为我正在重新考虑整个项目的分支策略。

Answer 1

我要拿你的图表重新整理一下：

                                          /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/--\
              /           /      /                          \
     /------------alpha--/------/---\                        \
    /                                \                        \
------------trunk--------------------(a)----------------------(b)------------------>

首先，删除trunk，因为您没有使用它。是的，你正在合并回主干，但你永远不会从中获取代码。相反，beta来自alpha而gamma来自beta。不妨将自己的所有努力归结为一个你从未真正使用的代码行：

                                          /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/
              /           /      /                      
     /------------alpha--/------/                    
    /                                      
trunk

现在，让我们理顺您的图表，以便主要的开发线很好而且笔直：

trunk-alpha-------beta-----------------------gamma-------------------------->
            \           /      /       \                /
             \---alpha-/------/         \---beta-------/

最后翻转一切......

             /-alpha-\-----\            /--beta-------\
            /         \     \          /               \
trunk------/--(beta)---\-----\--------/-(gamma)---------\------(gamma)-------->

有你的行李箱！

我知道你在做什么。你没有在trunk上编码，因为trunk代表你的发布。在原始图表中，trunk上有两个版本。点（a）将分支alpha合并到主干，而点（b）将分支beta合并到主干。这代表您的Release alpha和Release beta。

然而，这就是标签的用途！您在版本上制作了标记，您的标记现在代表您的版本。而且，它更好，因为标签会保留文件的历史记录。

假设您在Point（b）处转到主干并记录特定文件。您在Point（b）处看到该文件，并且您在Point（a）处看到另一个版本。但是，您不知道该文件在点（a）和点（b）之间是如何变化的。事实上，你甚至不知道谁的发布应对特定的变化负责。

但是，如果您在分支上执行了标记而不是将代码合并回主干，则会看到该文件的整个历史记录都返回到文件的第一个版本。 Subversion的日志命令（如果你不使用--stop-on-copy开关）将带你从标签下降到分支测试版并返回到主干。

啊，你说，但我如何才能看到发布alpha和发布测试版之间的差异？在我的计划中，我可以看看行李箱的历史！

但是，如果您需要查看一个版本与另一个版本之间的所有更改，您可以轻松地在两个标记之间进行差异。而且，正确的是它们是标签，更容易找到实际的发布版本，而不是试图弄清楚trunk上的哪个版本代表你的版本。

所以，你确实有一个主干，但你不要这么称呼它。

Answer 2

对主干范式（或者在git世界中，开发）的需求主要是需要一个尖端开发（特征分支）和质量控制措施（发布分支）相遇的点。它是所有活动分支的共同基础，主要通过它们与主干的区别来定义。

大多数项目都有中继线，大多数认为自己没有的项目都有，但是没有意识到。主干是项目的分支，它接收所有新功能，而不是要终止。如果您有多个具有此属性的分支，它们要么相等，要么彼此相距太远，以至于您有两个项目。树比喻在这里真的很棒 - 有两个树干，有两棵树。

虽然替代模型一开始看起来很好，但人们常常发现不止一个永久活跃分支对团队沟通至关重要。主干的优点在于，开发功能的团队中的任何人都可以从主干分支，开发，合并到主干并且快乐。使用多个活动分支，您将必须合并到多个分支或遭受功能分叉与所有错误的调试和用户支持。这是采用中继方案的主要原因。 Vincent Driessen has written a splendid article about this development model，一旦你用trunk替换devel分支，它也适用于SVN。

您似乎确实遵循了项目的主干方案。您的年轻分支（示例中的伽玛）实际上是项目的主干，因为它们接收新功能。较旧的分支（alpha和beta）会收到错误修复程序，这些修复程序稍后会合并到您称为trunk的分支中。但是，由于你从不再从主干中分叉，而只是从gamma中分离出来，因此不需要从alpha和beta合并。 Trunk似乎具有最少的功能和最稳定（最旧的分支），这与正常的主干逻辑相反。

因此，您可以通过一个主干来表示您的项目结构，该主干遵循示例中的最上面的行（从“主干”分支到“alpha”到“beta”到“gamma”）和多个发布分支（“alpha”和“beta”）合并到主干并打算终止。这样，您已经擦除了一个不必要的分支（标记为“trunk”）并且具有更容易的合并方案。

这种用法与您对“同时开发两个或多个版本”的要求形成对比，但是看看您的架构，我认为只有一个版本会收到新功能。如果我认为错了，请澄清这一点。

Answer 3

它让我想起 Debian 中的稳定 - 测试 - 不稳定版本。
您的模型完全有效，只要它代表您的工作方式。

以中继为中心有一个好处：无论你拥有多少个分支，主干通常是当前开发中最新的稳定版本。

在多版本项目中是否需要干线

3 个答案: