git 经验谈(三):团队分支管理

1,931 阅读4分钟

这篇文章是 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 流程会是这个样子:

git flow

那么按照这个管理方式,测试是如何进行的呢?首先是随着 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 经验谈(三):团队分支管理

参考的文章