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

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

在这里，人们对树干的需求产生了怀疑

我在ReadBean和其他（Subversion的实用版本控制）中读过SVN的书，所有这些都建议使用以主干为中心的开发模式。我不知道在我的情况下，这是否适用，是否存在成功使用其他模式的具有多版本发布周期的其他项目

为什么建议使用以中继线为中心的模式？ 版本分支越来越远离主干有什么问题吗？ 我认为这个模式与主干的集成有什么意义

/-----gamma-----/(3)----------> / / /----beta---/(1)---/(2)--/---beta--------/--\ / / / \ /------------alpha--/------/---\ \ / \ \ ------------trunk--------------------(a)----------------------(b)------------------> /-----伽马射线------/（3）---> / / /----β-/（1）-β-/（2）-β--------/--\ / / / \ /------------阿尔法--/--/--\ / \ \ ------------中继线-----------------------------（a）-----------------------------------（b）---> 编辑：

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

• 阿尔法：功能A
• 测试版：功能A+B
• gamma：功能A+B+C

这意味着分支的所有功能都包含在以后的分支中（通过同步合并）。这些分支在稳定性级别（较老的分支更稳定）和功能性（较年轻的分支具有新功能）上有所不同

编辑2，在三叉戟回答之后：

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

---

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

它让我想起了稳定-测试-不稳定的版本控制，来自Debian
您的模型是完全有效的，只要它代表您的工作方式

---

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

主干范例（或者，在git世界中，是devel）的需要主要是需要一个尖端开发（功能分支）和质量控制措施（发布分支）的交汇点。它是所有活动分支的共同基础，这些分支主要通过它们与主干的差异来定义

绝大多数项目都有主干，而大多数认为自己没有主干的项目都有主干，但没有意识到这一点。主干是接收所有新功能的项目分支，不打算终止。当您有多个具有此属性的分支时，它们或者相等，或者彼此之间的距离太远，以至于您有两个项目。树的比喻在这里真的很棒——有两个树干的地方就有两棵树

虽然替代模型在一开始似乎很好，但人们往往会发现，一个以上的永久活动分支对团队沟通是致命的。主干的优点是，开发特性的团队中的任何人都可以从主干中分支、开发、合并到主干中并感到高兴。如果有多个活动分支，您将不得不合并到多个分支中，或者在调试和用户支持都不好的情况下遇到一个功能分支。 这是采用中继方案的主要原因，用主干替换devel分支后，这也适用于SVN

看起来您的项目实际上遵循了主干方案。您的年轻分支（示例中为gamma）实际上是项目的主干，因为它们接收新功能。较旧的分支（alpha和beta）会收到错误修复，这些修复稍后会合并到称为trunk的分支中。然而，由于您再也不会从主干分叉，而只是从gamma分叉，因此从alpha和beta合并是不必要的。主干似乎具有最少的特性和最大的稳定性（最古老的分支），这与正常的主干逻辑相反

因此，您可以通过一个主干来表示您的项目结构，该主干遵循示例中最上面的行（从“主干”到“alpha”到“beta”再到“gamma”）以及多个发布分支（“alpha”和“beta”），它们规则地合并到主干中并打算终止。这样，您就删除了一个不必要的分支（标记为“trunk”），并且有了更简单的合并方案

---

这种用法与“同时开发两个或多个版本”的要求形成对比，但从您的模式来看，我认为只有一个版本接收新特性。如果我想错了，请澄清这一点。

我将把你的图表重新整理一下：

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

首先，删除主干，因为您没有使用它。是的，您正在合并回主干中，但您从未从中取出代码。相反，

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应该代表您的发布。在原始图中，主干上有两个版本。点（a）将分支alpha合并回主干，点（b）将分支beta合并回主干。这表示您的发行版alpha和发行版beta

然而，这就是标签的用途！你做了一个