版本控制模式

    分支所有者&方针

    下面是要遵循的一条简单规则。

    规则：每个分支（即使是主干分支）都拥有一个所有者和一条方针。

    不遵守上述规则，我们只能得到一片混乱。方针说明按照本规则，什么样的内容可以检入到当前分支中。所有者是负责定义和检查规则执行情况的人。

    “完成”概念

    一个用户故事怎么样才算“完成”？更明确地说，团队什么时候才可以把一个用户故事移入到任务版上的“完成”一栏之中？这又到底意味着什么？

    我会给出下面的假定。

    假定：“完成”的定义=“可发布”。

    所以当一个团队成员说某个用户故事已经“完成”，并将故事卡移入到“完成”一栏中之后，客户就可以马上跑到房间中说：“太好了！我们现在就上线吧！“，而且团队中没有人会说：“别，先等等。”

    你可以使用任何你喜欢的“完成”的定义。但是要记得——如果定义中没有完全包含“可发布”的含义，你就要好好想想了：在“完成”定义中没有包含哪些内容？谁会来补齐这些内容？什么时候？如果在“完成”之后出现问题，又会发生什么？

    “完成”分支

    当一个故事“完成”后，它需要有一个落脚之处。使用我的关于“完成”的定义（“可发布”），就意味着系统中的某个分支可以发布，这样该用户故事对应的功能就可以进入到生产系统之中了。这就是“完成”分支。

    任何分支都可以是“完成”分支。我将会使用主干作为“完成”分支（这是一个不错的开始）。有时这被成为“主线”。

    假定：主干作为“完成”分支。

    主干方针：

• 任何时候都可以发布
• 希望尽早发布

    “任何时候都可以发布”，这意味着：在任何时候，产品所有者都可以基于主干的最新版本，发布新版本的产品。

    下面是一个示例。

    蓝色的线表示主干。每个绿色的球形图案表示一次代码检入活动。可以看到在本次Sprint中共检入了5次内容。虽然通常我们是在每个Sprint结尾时才进行发布，不过还是可以在任何时候从主干中发布产品。如果在接近Sprint结束时，有一半的团队成员生病，因此导致没有时间完成故事#5，我们还是可以进行一次发布。当然，我们也可以选择先不发布，以等待团队在另一个Sprint中完成故事#5。

    “希望尽早发布”意味着如果我们不想让某个故事相关功能上线（或者说不关心它是否上线），就不要检入该故事相关的代码。如果我不希望发布上图中的故事#3，这个分支就被我毁掉了。由于这个分支不再是可发布的，我就违反了分支的方针。

    规则：不要在单一分支上合并不同的发布周期。

    何时创建额外分支？

    新分支的创建越少越好。下面是一条基于经验的原则。

    推荐：只在下面这种状况下才创建新的分支：当需要检入新的内容，而且没有哪个现有的分支能够在不违反自身方针的状况下完成本次检入。

    工作分支

    好，假设我们已经有了一个很好、很干净的主干，并且在任何时刻都处于“可发布”状态。

    等一下。“可发布”意味着已完成集成测试。这就意味着我们必须要 运行集成测试。也就是说我们要在向主干检入代码之前要运行集成测试。

    那我应该向何处检入我认为已经完成、但是在检入主干前需要进行验证的代码呢？当然，我可以在本机上完成测试，并直接将通过测试的代码检入到主干之中。但这还是有点吓人，我相信大家都遇到过“嘿，但是它在我的机器上运行没有问题啊”这样的事情。

    另外一个问题是“好吧，我完成了今天的编码任务，现在要回家了。我该把代码检入到哪里？还没有测试过呢，所以不能检入到主干中。我想把它检入到别的地方，这样其他的团队成员就可以在其基础之上继续工作了”（敏捷团队是采取代码集体所有制的，对吧？）。

    你看，我们有希望检入的内容，但是不存在不违反分支方针就可以进行检入的地方。这就是建立新分支的一个合理原因了。

    我们可将此称为工作分支，团队所有成员都可共享该分支。有人称其为开发分支。

    团队A的工作分支方针：

• 代码完成编译和构建，并通过所有的单元测试。
   

    很好，现在我们有两个分支了。一个稳定的分支（主干）和一个稍微不那么稳定的分支（团队分支）。团队分支是红色的，表示它不太稳定；例如：这个分支通过了单元测试，但是它可能还没有完成集成测试，所以还没有稳定到可以发布的状态。好，现在团队有地方可以检入正在进行中的工作了！

    嗯，那要是需要同步不同的分支时应该怎么做呢？往下看。