不过还是会有一些原因让我们不想马上发布新故事。例如：

发现了严重的缺陷，实质上意味着主干在发布时已经有问题了。也是说sprint 2的故事都是在一个有问题的基础上构建的。在必须处理新的故事之前，我们会想要修复这个基础。
也许利益相关者不希望在sprint当中发布新的功能。
从主干中发布包含新功能和全部已有功能的新版本，也许需要一段时间才能完成；所以我们需要一个“hotfix”机制来更快地修复问题。
我们具体该如何做呢？

创建一个名为“发布1.0”的发布分支，基于它在发布时的主干内容。
在发布分支上针对缺陷打补丁。
在发布之后，马上将发布分支合并到主干之上（这样补丁程序会包含在未来的发布版本之中）。


注意我们在发布1.0.0版本时没有必要创建“发布1.0”分支，可以等到问题出现时再做。这样以来，除非真的需要建立某个分支以让我们对其做些什么，我们不必创建额外的分支。

大图景
好，现在我已经给出了如何使用该模式的详细范例。让我们往后站一点儿，看看整个的图景是什么样子吧。

在主线模型中，一个分支被称为一条代码线（实际上，分支可以被人物是一条代码线的实现）。有时这些被成为流。

一条代码线的上级（也是该代码线的起源代码线）被称为它的基线。主线是没有基线的代码线。

所以在上面的例子中，我们可以总结出：

主干是我们的主线。它不是没有上级么？
其他所有代码线（发布版本1.0，团队A的工作分支，团队B的工作分支）都以主干作为基线。
下面是一个更复杂的例子：

这个图告诉我们：

项目X的代码线衍生自主线。该项目目前已完成，所以分支结束了。
团队A有一个衍生自主线的活跃工作分支。
团队A还有一个衍生自工作分支的、正在进行中的Spike（译注：Spike是指团队集中精力在短时间内尝试实现一个功能的活动。）。
发布版本2.3已关闭，因为2.3已经从生产系统中撤出而且不再会被维护。
每条代码线有一个相对其基线的坚固水平，也是说每条代码线要不比其基线更坚固，要不不及其基线坚固（更柔软）。

一条坚固的代码线是稳定的，通过测试的，很少变更而且临近发布。
一条柔软的代码线不稳定，很少测试，经常变更而且远离发布。
在绘制代码线时，坚固的代码线分支向上，而柔软的代码线分支向下。观察上图，我们可以总结出：

发布版本2.3比主线更坚固。
团队A的工作分支比主线更柔软。
团队A的spike比团队A的工作分支更柔软。
使用上述描述绘制图表，对于展示分支历史来说很有用；但是如果同时有很多分支存在，可能带来混乱。下面是一个更清晰的格式，仅展示了当前存在的代码线以及它们的衍生出处。

我建议以此格式绘制你的分支图，而且可以将其挂到团队所在房间的墙上。在讨论集成问题时参考此图真的很有帮助。

所有的变更都应沿着所在的线索发展，这是一条很重要的规则！所以不能直接从团队A的工作分支向团队B的工作分支中合并代码，这会导致很多混乱。实际上，在团队A工作分支中发生的变更应该流回到主线中，再向下进入到团队B的工作分支中。

任何位于主线之上的代码线都可以称为发布代码线，意味着一个比主线更坚固的代码线。

任何位于主线之下的代码线都可以称为开发中代码线（或工作代码线），意味着一个比主线更柔软的代码线。

协作黄金规则：

-总是接受稳定的变更。

-绝不强制使用会导致不稳定的变更。

那么这对于不同类型的代码线意味着什么呢？

上图以彩色的方式说明了：

任何时候在发布代码线上的变更，都应该立即合并到其基线中，并发布到主线上。
例：在2.4.2版本中修复了一个bug。这应该立即合并到2.4版本中，并将其合并到主线上。
一个发布代码线永远不要从其基线接受变更。
例：新的代码检入到主线中。该变更不应进入2.3版本和2.4版本。
变更应持续从基线流入到开发代码线中。
例：任何针对主线的变更应该迅速向下流入到团队A和团队B中，并从团队A向下流入团队A的spike中。
开发代码线的变更只有处于稳定点时才能发布到基线中。
例：团队B只有在一个故事完成并通过测试后才能向主线合并变更。
无论变更何时应用到代码线及其基线，有些合并是必须要做的。因为代码合并是一个很容易犯错误的操作，我们希望在两条代码线中稍柔软的一条上进行。一旦合并完成而且通过检验，我们可以将合并的代码复制回更坚固的代码线。

将坚固代码线比柔软代码线绘制得更高，使用这个惯例，我们可以推出一个简单的规则：

规则： 向下合并，向上复制

示例：团队A注意到主线已经更新了。他们将变更向下合并到自己的开发代码线，并修复任何冲突。只要团队A的开发代码线达到稳定的一个点，他们可以将代码复制回主线。当然，他们必须检查同时主线上没有发生任何变更。

模型的变种
“版本控制模式”一节描述了一个如何实施主线模型的范例。

“大图景”一节以更通用的方式描述了主线模型。

本节中，我将针对如何实施该模式提出一些典型的变种。

“完成”的定义不必一定是“可发布的”。
先确定“完成”一词的任何定义，然后确保有一个分支可以容纳根据该定义已经“完成”的故事。不过还是要注意别遗漏重要的内容。如果集成测试没有包含在“完成”中，那什么时候进行集成测试呢？