发布分支

    假定我们完成了sprint 1并发布了系统的1.0.0版本。现在，我们在进行sprint 2之中的工作时，有人报告说之前发布的版本中发现一个严重的缺陷！不！我们该怎么办？

    最简单的方式是：在主干上修复该问题，并发布1.1.0版本。这就是说在sprint 2中任何新实现的故事都会包括在新发布版本中。理论上来说，这样做没有问题；因为主干是“完成”分支，而“完成”的定义就是“可发布的”。所以主干上的内容无论何时都是我们要发布的东西。

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

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

    我们具体该如何做呢？

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

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