|
规则：每天都从主干向你的工作分支中合并代码。PgMp.mypm.net
转自项目管理者联盟
每天开始工作时，我所在团队中的某人负责将代码从主干中合并到我们的团队工作分支中(等同于“跟上”主干中发生的变化)。www.mypm.net
如果我的团队(团队A)发现一个代码冲突，我们会马上解决它——这是优先级最高的事情!如果我们需要团队B的帮助(或者是开发与我们发生冲突的代码的负责人)，找他们过来，一起工作，把问题解决掉。重要之处在于我的团队要负责解决问题，而且我们要在自己的工作分支上(而不是在主干上)完成。club.mypm.net
规则：在最不稳定的分支上解决冲突。training.mypm.net
当然，如果人们不经常向主干发布代码，那从主干合并代码就是浪费时间了。除非有人发布工作到主干上，团队A和团队B之间的任何分歧都会是不可见的。所以接下来的规则如下：项目经理博客
规则：经常从工作分支向主干合并代码，例如每完成一个故事之后。不要等到sprint结束后再做这个工作!PgMp.mypm.net
注意这里有一个有趣的副作用：项目管理者联盟
副作用：先检入代码者为王!项目管理培训
如果两个团队正在开发的代码互相冲突，后一个检入的团队必须负责解决冲突问题。这是一个好的副作用，因为它可以鼓励团队尽早检入代码。:o)项目管理培训
下面是一个完整Sprint的示例图：项目管理者联盟
项目管理者联盟
两个团队进行了一次6天的sprint。团队A准备实现“预订”和“取消”。团部B准备实现“发票”和“黑名单”。让我们看看发生了什么。项目管理培训
项目管理者联盟
Sprint完成了!除“黑名单”之外，所有的故事都完成了。但是没关系，我们还是可以发布的!因为我们是以增量的方式完成合并与集成的工作。如果我们等到sprint结束再做，任何分叉的代码就会在错误的时刻发现——此时我们能够用来修复问题的时间最少。项目管理者联盟
发布分支项目管理论坛
假定我们完成了sprint 1并发布了系统的1.0.0版本。现在，我们在进行sprint 2之中的工作时，有人报告说之前发布的版本中发现一个严重的缺陷!不!我们该怎么办?项目管理者联盟
最简单的方式是：在主干上修复该问题，并发布1.1.0版本。这就是说在sprint 2中任何新实现的故事都会包括在新发布版本中。理论上来说，这样做没有问题;因为主干是“完成”分支，而“完成”的定义就是“可发布的”。所以主干上的内容无论何时都是我们要发布的东西。bbs.mypm.net
不过还是会有一些原因让我们不想马上发布新故事。例如：项目管理者联盟
发现了严重的缺陷，实质上意味着主干在发布时就已经有问题了。也就是说sprint 2的故事都是在一个有问题的基础上构建的。在必须处理新的故事之前，我们会想要修复这个基础。项目管理者联盟
也许利益相关者不希望在sprint当中发布新的功能。club.mypm.net
从主干中发布包含新功能和全部已有功能的新版本，也许需要一段时间才能完成;所以我们需要一个“hotfix”机制来更快地修复问题。blog.mypm.net
我们具体该如何做呢?www.mypm.net
创建一个名为“发布1.0”的发布分支，基于它在发布时的主干内容。项目管理者联盟
在发布分支上针对缺陷打补丁。转自项目管理者联盟
|
