那么这对于不同类型的代码线意味着什么呢？
上图以彩色的方式说明了：
- 任何时候在发布代码线上的变更，都应该立即合并到其基线中，并发布到主线上。
- 例：在2.4.2版本中修复了一个bug。这应该立即合并到2.4版本中，并将其合并到主线上。
- 一个发布代码线永远不要从其基线接受变更。
- 例：新的代码检入到主线中。该变更不应进入2.3版本和2.4版本。
- 变更应持续从基线流入到开发代码线中。
- 例：任何针对主线的变更应该迅速向下流入到团队A和团队B中，并从团队A向下流入团队A的spike中。
- 开发代码线的变更只有处于稳定点时才能发布到基线中。
- 例：团队B只有在一个故事完成并通过测试后才能向主线合并变更。
无论变更何时应用到代码线及其基线，有些合并是必须要做的。因为代码合并是一个很容易犯错误的操作，我们希望在两条代码线中稍柔软的一条上进行。一旦合并完成而且通过检验，我们就可以将合并的代码复制回更坚固的代码线。
将坚固代码线比柔软代码线绘制得更高，使用这个惯例，我们可以推出一个简单的规则：
规则： 向下合并，向上复制
示例：团队A注意到主线已经更新了。他们将变更向下合并到自己的开发代码线，并修复任何冲突。只要团队A的开发代码线达到稳定的一个点，他们就可以将代码复制回主线。当然，他们必须检查同时主线上没有发生任何变更。
模型的变种
“版本控制模式”一节描述了一个如何实施主线模型的范例。
“大图景”一节以更通用的方式描述了主线模型。
本节中，我将针对如何实施该模式提出一些典型的变种。
“完成”的定义不必一定是“可发布的”。
先确定“完成”一词的任何定义，然后确保有一个分支可以容纳根据该定义已经“完成”的故事。不过还是要注意别遗漏重要的内容。如果集成测试没有包含在“完成”中，那什么时候进行集成测试呢？
主干不必是主线
这个模式需要一条主线才能进行下去，不过不必是主干（虽然在大多数情况下，使用主干是很自然的选择）。
团队不一定必须有自己的分支
当然可以有多个团队共享同一分支，甚至直接在主线上展开工作。只要保证遵循分支的方针即可。
通常，团队希望有自己的分支，以避免未完成的故事在多个团队之间造成干扰。
不必每次都创建一个全新的发布分支
可以使用同样的发布分支，而不是在每个sprint结束后都创建新分支。那个分支可以称为“最新生产系统”或其他类似的名字。如果在生产系统中总是保持只有一个版本，这当然是很好的模型。
不必在每个sprint结束后都进行发布
可以在每个故事完成后进行发布。或者每三个sprint完成后发布一次。确定你自己的步伐。
不必针对每个故事都运行回归测试
如果在你的环境中，回归测试或集成确实很难实际操作，那么可以在sprint接近尾声时进行。这样就可以针对一批故事进行测试和集成的工作。你自己要承担相关风险。如果回归测试和集成属于“完成”的定义，这可能意味着你在sprint末尾时可能会遇到问题，导致没有任何故事完成的风险。
FAQ
持续集成（CI）在这个模式中如何使用？
CI服务器应该针对哪个分支运行？这要根据具体情况，不过下面的叙述是一个好的起点。
假定主干的方针是“完成而且可发布”，而每个工作分支的方针是“通过单元测试”：
- 对每个工作分支来说，CI服务器自动并持续地检查构建和运行所有单元测试的状况。
- 如果有任何失败，就给出一个红色警告。让机器冒烟……
- 对每个工作分支来说，CI服务器自动并有规律地（如果不能持续地）运行集成测试和回归测试。
- 如果有任何失败，就给出一个分离的警告。因为这不是当前分支的方针。
- 当有人考虑从工作分支向主干发布代码时，要触发该手工测试，以检查故事是否“完成”。
- 对主干来说，CI服务器自动并持续地运行集成测试和回归测试。
- 如果有任何失败，就给出一个红色警告。让机器冒烟、触发警笛、USB火箭发射器，再把国民防卫队叫来。
该版本控制模型使用哪种工具最合适？
不确定。我知道Perforce是可以的，我想subversion应该也没有问题，但是对于CVS我不敢打包票。欢迎任何新的建议。
不过要记得一个重要的事情——切换工具的成本要比不能有效协作产生的成本低得多！所以搞清楚你想怎么做，然后找到合适的工具来支持。
与用户故事无关的检入怎么处理？
不是所有的代码变更都必须与某个用户故事相关的，在例子中，我只是为了描述的清晰才这样做。无论检入何种类型的代码（或文档之类），同样的模型也是可用的。
合并代码很麻烦，所以我想做得越少越好！
恭喜，你得了合并恐惧症——对于合并代码的非理性恐惧！合并让你觉得麻烦，是因为做的太少了。合并得越多，痛苦就越少。:o)
