如果没有并行开发，基线也许就是版本机上的一个简单文件夹。
如果进行并行开发，那么基线就是具有了指定标签的版本的集合。
在进行并行开发的时候，我们希望基线是流动的，会随着我们的期望变化。比如说我们在1.1版本捉虫的时候开始了2.0版本的开发，我们希望2.0的起始版本保持与1.1的最终版本一致。这里基于一点假设，假设2.0版本不回全面改写1.1版本的代码，而是小部分的改动。这种假设依赖于良好的设计。在扩展功能的时候，对原有代码的改动尽量少。假设我们有A1 - A10 10个文件，在2.0版本中，为了增加新的功能，我们改动了A9，A10两个文件，在1.1版Preview以后，1.1版本中因为修改BUG，又改动了A8，A9两个文件。我们要使2.0版本的初始代码包含1.1版本的最总代码，我们需要做的事情就是将A8按照上篇所介绍的第一种合并场景进行合并，即合并到基线中（简单的移动基线标签），而A9文件，则除了要合并到基线中意外，还要进行上篇所介绍的的第三种场景的合并，即将基线的变化合并到已经发生改变的2.0版本中（移动基线标签并进行合并）。通常，基线变更涉及的文件数应该尽量少。
这就是流动的基线。因基线的变更需要许多人工判断的介入，所以基线应该是稳定经受考验的版本。我们要保证基线的稳定性，不是所有的人都可以随意改变基线，基线也不是每时每刻不断的变化（上篇已经介绍了版本的强制控制）。事实上，基线的变化越少越好。通常基线发生变化也存在常见的场景。
◆ 1.1版本Preview。如果1.1版本是在分支上进行开发的，那么VM希望将分支上的代码完全合并到主分支上，以避免开发者的代码检入影响版本的稳定性和分支的长期存在对于版本服务器性能的影响。这种合并的工作量比较大，必须借助于一些自动合并的工具进行。
◆ 版本交替期，即1.1版本已经开始Preview但是并没有RTM，2.0已经开始Coding。这个时候1.1版本的任何将要发布的修改都应该反映到2.0版本的初始代码中，即使是设计的改动（最好不要有）。
◆ 补丁（包）发布前，Bug的修改明显将导致基线的移动。
跟版本强制控制一样，基线的变更也是并行开发的基础。
文章来源于领测软件测试网 https://www.ltesting.net/
