关于基线版本、基线那点事儿

直到现在，就是此时此刻仍然不知道基线版本、基线是个什么概念，但是仍然想记录一下。不知道哪一天就会明白，但是肯定是随着工作的深入能理解的，嘿嘿，不多说，记录。

1、“基线”是一个很常见的术语，在配置管理和项目管理里面都能看到，而且还有很多衍生的术语，例如基线提升、基线化、基线审计，等。 现在我觉得我们通常看到的“基线”这个术语有两个意思： 

1）代表多个源代码文件的一组版本。 比如有三个文件，aaa.c、bbb.c和ccc.h。可以对这三个文件做一个基线，取aaa.c的版本1.1，取bbb.c的版本1.3，取ccc.h的版本1.0。(1.1,1.3,1.0)就是一个基线。换 句话说，通常在vss和cvs里面做label，就是在做基线。 这种基线对“构建审计”特别有用：在做build的时候，可以先对所有源文件做一个label，取名为"Build2394"，然后再编译、集成。这样，以后如果要找到和build 2394对应的原文件，只需要 到vss或者cvs里面把所有文件对应label Build2394的版本取回来就可以了。

 2）代表文档的一个稳定状态。 比如有一个项目设计文档，当设计基本完成，开发即将开始的时候，需要把这个文档固定下来，内容不能再频繁改变，否则开发人员就无所适从了，可能导致每个人所参照的文档并不是同一个文档。用一句上海这里的生活用语来 说，就叫做要把这个文档“敲定”。 一个文档如果经过讨论被通过了，被固定了，就可以说这个文档被“基线化”了，然后所有人就可以在这个“基线”的基础上工作。 当然，文档不可能一成不变，所以当对文档的修改仍然会不断进行，但这种修改并不会随时随地的添加到被“基线化”了的文档中去。因为既然是“基线”，就不能随便动。 但是到了一定时候，修改积累到一定程度，就需要把很多修改合并到原来的文档中去了，并生成一个新版本的文档作为团队中所有的人的参考标准，并把老的版本淘汰掉。这就叫做“基线提升”。

 3)合同基线当你和客户讨论后，“敲定”的合同 4）发行基线 你会对你要发行的代码，文档版本进行label, 比如Release2.2。

2、基线管理：文档库管理员可以对文档库创建“基线”，所谓“基线”，是文档库的某一时刻的“快照”，即创建基线的时候，文档库中所有文档的当前版本的一个整体拷贝。例如，当一个项目进行到某个里程碑，对项目文档库中全部文档需要创建一个基线，以整体记录此阶段的成果。

3、来自百度搜索：

在工作中，基线版本是必不可少的。基本上是完成某一阶段的开发时，就会对项目版本打上Label作为基线版本。那版本要怎样才算是基线版本呢？下面纯属个人想法。
　　（1）相对于其他的版本来说，基线版本必须是稳定状态的，并且是已通过测试的。因为基线是以后版本开发的基础，可以为个性化和定制化开发提供一个稳定的开发版本。
　　（2）基线版本必须是可运行的，因为如果一个不可运行的基线版本如何为后续的开发提供一个稳定的状态呢？
　　࿰