git 经验谈（三）：团队分支管理

这篇文章是 git 系列第三篇，想介绍一下团队分支的管理。在我们的开发工作中，为了对流程进行更好的管理，更好地交付产品，应该充分地利用分支这个功能。这里我想介绍一下自己认为比较完备的、通用的 git 分支管理策略。开始之前，要先说明一下我认为的“通用”是针对什么样的开发流程的，它的特点如下：

• 有固定的迭代周期，一般是两周。
• 每个迭代结束后进行一次产品发布。迭代周期中不发布产品，除非是 hotfix / 紧急问题。
• 产品只有一个主版本。大多数基于 web 的产品都是这样的，不符合这个条件的产品一般是针对不同客户、国家等条件同时维护着多个正式版本。

下面就列一个表格来说一下具体的分支划分：

分支名	说明
dev	开发工作的主分支。迭代开始时，每个开发人员从这个分支创建自己开发任务的 feature 分支；迭代周期的开发工作结束时，用这个分支的代码进行产品发布。（你可能觉得从 dev 分支发布产品有点问题，我在后面做解释）
master	线上产品代码的分支。产品发布后，dev 分支的代码被 merge 到这个分支。当线上出现紧急问题，需要进行 hotfix 时，从这个分支创建 hotfix 分支。
f_xxx	以“f_”开头的开发任务分支，也叫 feature 分支。从 dev 分支创建，开发任务完成后 merge 到 dev 分支。
hotfix_xxx	以“hotfix_”开头的 hotfix 分支。从 master 分支创建；通过发布此分支修复线上紧急问题。问题修复后，要把当前 hotfix 分支的代码 merge 到 master 和 dev 分支。

根据表格中的描述，实际开发中的 git 流程会是这个样子：

那么按照这个管理方式，测试是如何进行的呢？首先是随着 feature 分支的开发完成，测试工程师在 dev 分支上进行对应的功能测试；hotfix 的测试要在 hotfix 分支上进行，不能在合并后的 dev 分支上进行；feature 分支和 hotfix 分支都合并到 dev 分支后在 dev 分支进行针对用户体验和产品流程的测试。

最后，产品 / 紧急修复发布后，别忘了在 master 分支打 tag。

缺陷

这个管理方式有一个问题，那就是没有预发布分支（release），或者说开发分支和预发布分支没有分开，只用了一个 dev 分支。上面表格的括号中要解释的也是这个问题。使用 release 和 dev 分支分开的方式有以下优势：

1. 把针对功能的测试和针对操作流程的测试隔离开
2. dev 分支的代码合并到 release 分支后可以更早地用于后续的开发工作

我为什么没有选用 dev 和 release 分离的方式呢？一方面我对以上两个优势没有强烈的需求，另外就是这样做需要频繁地合并代码，太麻烦了。结构复杂的产品和对测试工作投入较大的团队会因为优势1 而选择 dev / release 分离。如果想了解 dev / release 分离的方式具体是怎样工作的，可以参考这篇攻略：Git分支管理最佳实践，我就不在这里 copy 了。实际上这是一个老外提出的经典的版本控制系统工作模式，大而强，且麻烦... 原文在这里：A successful Git branching model 。

总结

我这篇文章提出的分支管理策略是根据自己的实践经验总结的，能满足基本的要求。但这也只是个通用的模板，如何制定团队的 git 分支管理应该根据自己的具体情况而定，产品形态、团队人员配置都会影响到版本控制系统的使用。谢谢阅读，欢迎提出你的看法！

本文的原文链接：git 经验谈（三）：团队分支管理

参考的文章

• Git 代码分支管理规范
• Git分支管理最佳实践
• A successful Git branching model