完成包括回归测试在内的工作

    当一个故事“完成”后，我们会把它移入到“完成”一栏中，并将相关内容从工作分支拷贝到主干中。主干必须一直保持可发布状态。此处有一个重要的暗示。

    规则：任何接触到主干的人，必须保证整个主干保持可发布状态——包括之前的全部功能！

    实际上，这条规则意味着：对故事A的测试，同样包括运行之前实现的故事的全部相关回归测试。如果上传代码后，故事A没有问题，但是之前故事的测试却通不过了，这是不行的。

    稍等。这是不是有点不合理啊？每完成一个故事就要运行所有的回归测试？

    嗯，首先我没有说运行所有的回顾测试。我是说所有相关的回归测试。我们已经有了一个干净而且可发布的主干作为基础，现在只是要添加一个故事而已！这是一个很小的增量变更。如果回归测试可以自动化完成，我们就可以全部运行了。要是有需要手工完成的回归测试，那我们就要有选择性了。

最后还是归结到了对风险vs成本的权衡之上。对于每一个手动的回归测试，我们应该评估运行它的成本（比如需要多少工作量来完成测试），同时评估发现任何重要缺陷的可能性，对二者进行权衡。当然还要加入自动化该测试的成本。:o)

    分叉代码（合并冲突）

    假设我正在兴高采烈地编写调用Widget类的代码，我却不知道团队成员Jim在一个小时之前进行重构时移除了Widget类。现在我们就有了< b>分叉代码。在花费更多时间编写其他调用Widget类的代码前，我希望尽早发现类似问题。

    规则：持续不断地（等同于尽早）将你的代码同步到工作分支中。

    这种同步是双向的。从工作分支中取得并合并最新的代码，然后检入你的代码。第一步可以叫做“跟上”（等同于我要知道其他人检入了哪些内容）。第二步可以叫做“公开”（等同于我希望我所做的更新可以让团队其他人都知道）。

    每小时同步一次是好习惯，基本上在进行任务切换或者没有处于某项工作进行中时，就可以进行同步。这不只是关于“我要尽快知道别人的代码是否与我的相冲突”，还包括“我希望其他人尽快知道我的代码是否与他们的冲突”。要记得不要违反工作分支的方针（通过单元测试等等）。

    该规则听起来很浅显，但是请允许我不断重申。我希望大家都能对其一清二楚，因为涉及到多个团队协作时，我们会再次使用类似的思维方式。