所谓代码分支是版本控制中的一个非常关键的概念。当开发到某个阶段的时候，可以交付一个版本，而主要的开发者则把精力投入到最新版本的开发中。第一个交付分支(2.0)中的一些问题，以及引入的新功能随后在RELENG_2分支中被修正，公司决定发布2.1版本；此后，2.x中的问题继续在RELENG_2中被修正，而一些安全更新，则被合并到2.1-RELEASE中(RELENG_2_1)。

    图5展示的是一个文件上的版本分支。实际的软件工程项目的源代码会由大量文件组成，尽管在本质上分支是针对每一个文件说的，但在被标注了同一分支名称的文件，就像版本标记一样，能够表达一组特定版本文件的集合。

    cvs的版本分支功能有一个很大的缺陷，即，大量文件的切分点(Branchpoint, 即某一个分支最初的版本号)在cvs中很难被指定(cvs支持按某一分支、某一特定时间、某一特定版本来提取文件，但通常不同的文件的版本号并不统一，特别是在大型项目中，肯定有某些文件因为被提交的次数很多，而版本号很“高”的情况)。为了消除这个缺陷，在实践上，我们采用版本标记与分支结合的方法，即，在划分新的分支之后，在这一分支的这些文件的版本上增加一个版本标记。

    例如：对于软件的2.0版，在划分时，将切分出RELENG_2(2.x)，RELENG_2_0(2.0)两个分支，而这时的文件的版本，同时被打上一个RELENG_2_0_0_BP的标记。这样一来，在以后比较版本时，我们可以使用RELENG_2_0_0_BP来指定这个版本。当不同的分支又增加了许多修改之后，这个标记将极大地减轻代码复审员的工作量。

    注意，代码分支并不仅限于版本上的用法。事实上，基于同一代码基础的多个不同的软件也可以采用代码分支的方法进行开发。而最终，这些代码还可以合并为一个。

    您可能已经注意到最左边的一组版本序列：1.1, 1.2, 1.3, 1.4, 1.5. 1.6。在cvs中，这一序列被称为“主分支(MAIN Branch)”。尽管并非必须，但习惯上，主分支通常是活跃的开发分支。在这个分支中，人们不断地引入最新的特性，当然，不可避免地，这也可能引发一些问题，而这些引入主分支的问题在随后将被追踪、修订。经过一段时间之后，被“沉淀”下来的代码可以进入另一个叫做“稳定分支”的代码系。

    这样的开发模式通常被称作“多头并进”模式，这样的模式在许多开放源代码的软件开发中非常常见，例如，Linux的单、双号版本、FreeBSD的-STABLE和-CURRENT[2]，等等。在一般的商业软件开发中，这种模式也相当常见，特别是在大公司的开发中。拥有多头并进这一能力对于大型软件的开发尤为重要，因为大型软件很可能包含相当多的模块，通过版本控制，问题能够很容易地被整个开发团队追踪。

    多头并进的开发环境中，开发人员可以在粗略熟悉了某个分支的代码体系的情况下参与开发或维护，这意味着，即使某个代码分支的维护人员突然离去，其他人也不用担心通盘阅读不同分支的代码可能造成的理解困难，换言之，对于新的维护人员的要求被降低，从而，软件的开发和维护过程能够更为有序地进行。

    据我所知，FreeBSD的软件开发过程极大地得益于多头并进的开发模式。下面简单地介绍一下FreeBSD所采用的软件开发模式：

    案例：FreeBSD开发模式中对于多头并进的应用

    FreeBSD包括了两个主要的开发分支：4-STABLE和5-CURRENT，以及若干安全分支。其中，4-STABLE(RELENG_4分支)代表的是FreeBSD 4.x系列的开发，其关注的焦点是系统的稳定性和性能；5-CURRENT(HEAD分支)代表的是FreeBSD 5.x系列的开发，它关注的焦点是尽可能多地引入最新的操作系统特性，全新的设计思想，等等。除此之外，还有一些被称作安全分支的分支，它们分别代表FreeBSD 2-STABLE, 3-STABLE, 4.6-RELEASE, 4.7-RELEASE, 4.8-RELEASE以及即将推出的4.9-RELEASE等等，但这些分支完全不引入任何新的特性，只有安全更新能够被加入到这些分支中。

    FreeBSD的“安全分支”是一个非常重要的概念，在FreeBSD的开发中，这些分支基本上只由一个包括了少量开发者(目前只有两人)的，被称为“FreeBSD安全官”的团队维护。对于很多用户来说，他们并不在乎操作系统是否拥有新的特性——他们不愿意尝试新版本的软件，因为现有的系统工作的非常好。这些用户使用“安全分支”的FreeBSD操作系统，因为他能够提供必要的安全更新，而操作系统特性并不会因此发生变化(无论这种变化是否能够改进性能，或提供一些眩目的功能，甚至支持新的硬件，因为用户的系统已经放在那里了)。

    CURRENT分支走的是另外一个极端。所有的新特性，一旦被特定的工作人员(committer)测试通过(大的变化需要核心团队，即core team的批准，但这种情况并不是很多)，就允许被引入CURRENT分支。尽管CURRENT分支在绝大多数时间都能够被正确地编译，但引入新特性有时会不可避免地带来一些问题，例如硬件适应性问题。

    在这两个极端之间，有一条中间路线，即STABLE分支。在CURRENT分支中提交的代码通常会被指定一个MFC(Merge from -CURRENT)时间，在这个时间之后，如果没有人提交关于代码的问题，则这些代码会被引入STABLE分支。

    这样，STABLE分支的代码几乎都是经过相当长时间测试的代码，对于大多数用户来说，STABLE分支是一个很好的选择。

    一般来说，FreeBSD中的代码会经历下面的历程：

    代码被引入CURRENT分支

    相关开发者获得来自用户的反馈; 在确认基本没有问题的情况下，代码被引入STABLE分支

    大多数最终用户使用STABLE分支的代码来支持他们的计算机

    我们可以看到，上面的开发模式同时照顾到了开发者和用户群体的利益。一方面，活跃的开发不会因为影响到了大量的普通用户而遭到指责；另一方面，在开发分支(CURRENT)的代码经过一段时间被引入STABLE，最终用户能够得到那些新的操作系统功能。

    事实上，上述开发模式已经被证明是相当成功的。由于开发过程中每一天都有相当多的人对新的CURRENT和STABLE分支的代码进行测试，因此，在最近的几年中，FreeBSD的开发一直呈现着良好的态势。