分支模式在SVN环境下的应用——主线（结构模式）

一、分支模式的相关定义

模式 主线
别名 主干、主锚线、本线、地线（Main Trunk, Main Anchor Line, Home Line, Ground Line ）
场景
    在开发和维护周期中，因为各种原因需要创建多条代码线，典型的代码线是发布线、维护线和集成线。这在采用每发布代码线、并行维护/开发线和重叠发布线 (或者其任何变形模式)的情况下尤为如此。随着项目的进行，会创建出越来越多的代码线，从而导致项目的版本树越来越宽。

 
连续的瀑布式分支（应该避免的情况）

问题
    怎样确保当前活动代码线的数量在可控范围内，以及避免项目的版本树过宽过深？

动机
    通常，每条代码线在某个时间点需要将变更集合并至其父分支。所以越多的代码线就意味着更多的合并，而越多的合并意味着越多的同步工作。
    当后续的版本发布时，看起来只有在当前版本的代码线上开创一个新的分支才算是合理的。

解决方案
    在每一个分支树中保持一个“主”分支或代码线作为主干，而不是持续的瀑布式从分支创建分支从而使分支树变得宽广而笨重（在每一对父子分支之间需要大量的同步工作）

 
拥有主线的瀑布式分支

    当为主发布创建代码线的时刻来到时，我们不会从前一个发布线创建新的发布线，而是将先前的发布线合并回主线，然后再从主线创建新的发布线。
    为特定代码线或分支合并回来的过程被称为“主线化”、“主干化”、“归位”、“锚定”或“接地”（"mainlining," "trunking," "homing," "anchoring," or "grounding."）。

变种 稳定接收线（也称为稳定主线、主集成线和基础集成线（Stable Mainline, Main Integration Line, Base Integration Line））
    保持一个稳定的，可靠的主要开发主干可以用来从其他代码线导入（接收）稳定基础。在代码线上不会直接发生开发工作，所有集成工作必须来自其他代码线（不是一个单独的离散的活动分支）。这个规则唯一的例外是为了保证代码线构建和功能一致性的集成变更。

（用以接收稳定基线的稳定主线——实际上就是通常所说的基线）

LAG开发线（也称为主开发线、中央线和主流）
    把主干作为最新的最好的（LAG）会一直进展的开发线，所有前面的发布的代码线都会在其退休后被合并入其中。主干作为下一步/最后的开发发布（不是维护，而是开发，包括显著的改进和新特性）的开发线使用，因此当B2发布的工作已经准备好开始，而A1发布已经完成或逐渐停止，则建立一个新的分支来结束A1的工作（见延迟分支），而LAG线则用来针对B2（最新的和最好的开发工作）发布的工作。

 
（LAG开发主线）

    对于特定代码线或分支合并到滞后（LAG）开发线的过程也可以称为"LAGging," "mainlining," "LAG-lining," or "mainstreaming."。
    尽管作为一个主线使用，LAG线也可以作为主线与稳定接收线结合：

 
（有一条稳定主线用于接收发布版本的LAG开发主线）

 

二、模式的分析

    主线模式及其变种主要试图从分支的结构上约束其不合理的扩展和延伸，而尽量使主线成为其他代码线创建的来源及合并的目标。稳定接收线（也就是通常所说的基线）用于接受并保存相对稳定的版本，通常情况下其只接受版本（通常情况下为直接保存版本的镜像而非合并操作）而不进行其他任何操作。

三、主线模式在Subversion环境下的实现

如上图所示实际上就是有一条基线伴随的LAG开发线模式，实现该模式相关的约束包括：

1、所有的代码线（不包括分支）都从主线创建
2、主线以外的代码线的合并操作都以主线为目标
3、基线只接受版本（直接保存版本的镜像而非合并操作）而不进行其他任何操作。

 

参见：SmartChange并行开发管理模块