Question

接下来我们来学习问题驱动的团队开发。

5.3.1　别急着敲代码，先建问题

下面我们开始学习团队开发的一系列流程。所谓开发，既可以是开发新应用，也可以是修改已有系统。重要的是，我们在打开编辑器敲代码之前，要先把即将着手处理的项目添加到问题跟踪系统之中。

在 Redmine 界面中填入标题和任务概述并完成添加后，我们将得到一个带有编号的问题（这里是“#2”）（图 5.8）。

图 5.8　Redmine 的问题界面

5.3.2　创建与问题编号同名的分支

获得问题跟踪系统分配的问题编号之后，我们就可以在 Mercurial 上创建一个与之同名的分支了。举个例子，如果问题的编号为“#100”，那么我们的分支名就对应为“t100”。

这样一来，我们负责的项目和源码的修改内容就一一对应起来了。等到我们完成了这部分工作，只要将 t100 分支合并到 default 分支，就能轻松完成发布工作，十分方便。另外，将“一个问题对应创建一个分支”用作项目方针来规范团队，可以有效减少恼人的多头现象（Multiple Head，即最新端变更集分成多个版本的现象）。而且，由于问题的编号与分支名一一对应，所以当我们想查看项目 #100 所修改的内容时，只需查看分支 t100 即可，非常方便。

◉ 主题分支与问题驱动开发

这种为单一问题（主题）而创建的分支称为主题分支。

一个项目拥有的主题分支数往往很惊人。我们没必要给每个主题分支都起一个有意义的名字。花大量时间在起名字上，有时反而会起出一些让人摸不清头脑的名字，倒不如机械式地起名来得方便，而且不会出现歧义。问题跟踪系统的问题 ID 一般都很独特，再加上它具备我们前面提过的那些优势，所以用它肯定万无一失。

像这样基于问题跟踪系统的问题来进行开发的模式就称为问题驱动开发。

专栏　明确区分分支名与版本修订号

主题分支的英文是 Topic Branch，所以名字前面都加了t。在 Mercurial 中，这还起到了区分分支名与版本修订号的重要作用。仅由数值组成的分支名很容易与版本修订号搞混，弄不好就会出现意外情况，所以应当尽量避免使用仅由数值组成的分支名。

5.3.3　让发布与分支相对应

从项目管理的观点讲，我们提倡设置里程碑并制定发布计划。而采用敏捷开发的项目还会基于迭代来制定发布计划。

在系统开发中，发布计划的重要性不言而喻。前面我们讲了问题与分支一一对应的好处，同样道理，将发布与版本管理系统的分支一一对应也能方便管理。

使用 Mercurial 时，default 分支是一个既定的分支，必然存在。因此我们规定“default ＝面向正式运行的分支”。然后假设现在有一个发布，我们从 default 创建一个新分支与它相对应（LIST 5.6）。

LIST 5.6　从 default 创建发布分支

$ hg update default
$ hg branch m1231

然后，基于新创建的发布分支派生出各个主题分支（LIST 5.7）。

LIST 5.7　创建主题分支

$ hg branch
m1231
$ hg branch t100

用作里程碑的分支并没有严格的命名法则，但为了表示其“里程碑”之意，我们用字母 m 打头。

m 后面可以是发布日期（上例中的 1231 表示 12 月 31 日），也可以是明确表示发布的特殊词汇（比如智能手机版的发布命名为 m_smartphone 等）。由于问题跟踪系统不会专门给里程碑分配特殊 ID，而且创建里程碑并不像创建主题分支那样频繁，所以我们完全可以给每个里程碑设置个性化的分支名。

5.3.4　分支的合并

刚刚我们通过创建分支将开发成果分割开了。各个项目都有对应的分支，分支之间的开发和提交相互独立。因此，当项目完成后，还需要将它合并回来。合并的规则很简单，保证只合并有父子关系的分支就行了（图 5.9、图 5.10）。

① 只在父分支和子分支之间进行合并。

② 子分支之间不合并。

③ 从子分支派生出来的孙分支不能直接合并到父分支。

上述规则必须严格遵守。

图 5.9　父分支与子分支之间的合并

图 5.10　一些应当避免的合并

如果合并了没有父子关系的分支，我们好不容易分割清楚的项目会再度乱成一团。这可能会导致问题里没提到的修改内容在不知不觉间混入，或者导致源码产生冲突，等等。想在其他分支中反映某分支的成果时也要遵守这一规则，先与它们共同的父分支合并，再反映到对象子分支里。

虽然这样做很麻烦，但在父分支中分享一些本不该出现的半成品会导致很多问题，所以请各位务必遵守。

只要按照我们这里学习的方法创建分支，一般不会遇到子分支之间合并或者孙分支向父分支合并的情况。如果无论如何都得进行这类操作，那就可以认定是分割项目与设置父子关系的阶段出现了问题，需要我们修改问题的内容或选择其他方法应对。

另外，在将子分支合并到父分支之前，一定要先在子分支中反映父分支的修改内容。因为在我们修改子分支的过程中很可能有其他人对父分支作了修改，所以要先将这部分修改吸收到我们的子分支中，保证“父分支和子分支之间的差别 = 我们对子分支作的修改”。

这样一来，即便子分支与父分支之间出现了矛盾，我们只要回到自己的任务分支中就能解决该问题。