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

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

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

多个团队??如果其他团队同时向主干中发布代码该怎么办？
假设有团队A和团队B。他们都是跨职能团队，并且一起开发一个航班订票系统。团队A的注意力放在开发订票流程之上，而团队B主要负责开发后台相关功能。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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