多个团队——如果其他团队同时向主干中发布代码该怎么办？

    假设有团队A和团队B。他们都是跨职能团队，并且一起开发一个航班订票系统。团队A的注意力放在开发订票流程之上，而团队B主要负责开发后台相关功能。

    假设他们现在要开始一个sprint，每个团队有两个用户故事要开发（通常一个sprint中会有更多的故事）。

 
    由于每个团队都要在发布代码到主干前进行测试，因此他们有各自的工作分支。

 
    现在我们遇到了一个有趣的问题。假定我在团队A中，而且有我们自己的工作分支。变更可能先在主干中发生，而不会先出现在我的工作分支中！为什么？恩，因为有另一个团队啊，他们每完成一个故事就会将其发布到主干中！

    所以在任何给定的时刻，在主干上都可能有我不知道的新代码。而且这些代码可能（但愿不会如此）会与我的代码冲突！也许团队B中的某人会重新命名Widget类，可我已经在代码中调用了它而且……呃……等一下，我们不是刚讨论过这个话题了么？

    没错，是同样的问题。解决方案也相同。但是范围有一点点不同。

    规则：每天都从主干向你的工作分支中合并代码。
 

    每天开始工作时，我所在团队中的某人负责将代码从主干中合并到我们的团队工作分支中（等同于“跟上”主干中发生的变化）。

    如果我的团队（团队A）发现一个代码冲突，我们会马上解决它——这是优先级最高的事情！如果我们需要团队B的帮助（或者是开发与我们发生冲突的代码的负责人），找他们过来，一起工作，把问题解决掉。重要之处在于我的团队要负责解决问题，而且我们要在自己的工作分支上（而不是在主干上）完成。

    规则：在最不稳定的分支上解决冲突。

    当然，如果人们不经常向主干发布代码，那从主干合并代码就是浪费时间了。除非有人发布工作到主干上，团队A和团队B之间的任何分歧都会是不可见的。所以接下来的规则如下：

    规则：经常从工作分支向主干合并代码，例如每完成一个故事之后。不要等到sprint结束后再做这个工作！

    注意这里有一个有趣的副作用：

    副作用：先检入代码者为王！

    如果两个团队正在开发的代码互相冲突，后一个检入的团队必须负责解决冲突问题。这是一个好的副作用，因为它可以鼓励团队尽早检入代码。:o)

    下面是一个完整Sprint的示例图：

 
    两个团队进行了一次6天的sprint。团队A准备实现“预订”和“取消”。团部B准备实现“发票”和“黑名单”。让我们看看发生了什么。

    Sprint完成了！除“黑名单”之外，所有的故事都完成了。但是没关系，我们还是可以发布的！因为我们是以增量的方式完成合并与集成的工作。如果我们等到sprint结束再做，任何分叉的代码就会在错误的时刻发现——此时我们能够用来修复问题的时间最少。