代码分支及版本管理规范

特别感谢 LeanCloud 团队的开发资源,虽然看了很多的 Git 的分支管理策略,LeanCloud 的 Git 分支管理规范很适合我们团队,此文档基本是翻版。

介绍

每个人使用 Git 有不同的使用习惯,无所谓对错,但是涉及团队协助,必须有一个统一的规范。

参考了TBD、GitHub Flow、git-flow 以及 AoneFlow 等不同分支管理策略,我们制定了此规范,特点如下:

  • 操作简单,不要像 GitHub Flow 这么复杂;
  • 可以确认任何时间发布的版本;
  • 如果有重大 bug,可以快速回滚到上一个稳定版本;
  • 修复紧急 bug,可以快速修复,而不用发布不该发布的内容;

分支

每个项目的有且只有 master 和 release 两个永久分支,开发中会用到 feature 和 hotfix 临时分支。

master分支

开发分支,所有开发的代码都须合并到此分支。

release分支

产品发布分支,主要用于发布产品版本。

feature分支

特性分支,每当开发新功能从 master 分支拉出。 为了不重名,feature这么命名:feature/用户代号-模块名-子模块(如果有的话)

hotfix分支

bug修改分支,发布版本有bug的时候,可以从 master 拉出分支进行修正。 每一个bug都要提交到工单中,工单都有一个数字的id,hot分支可以这么命名:hotfix/issue-工单id

tag 命名

  1. tag 只针对 release 分支,别的分支不需要打 tag。
  2. 客户端程序(如 App、小程序)遵照 major.minor.patch 的命名,如 2.3.1。
  3. 服务端程序(如 Api 接口、后台管理系统)以发布的日期命名,如 2018.5.20。
  4. 如果有 bug 修正,第 2 条直接最后发布号+1,如果上一个 tag 是 2.3.1,这个 tag 应该是 2.3.2,如果是日期命名,在后面增加小写字母,如 2018.5.20 后是 2018.5.20a,然后是 2018.5.20b。

新功能开发流程

  1. 从 master 分支创建 feature 分支;
  2. 开发调试完将 feature 分支提交到远程版本库;
  3. 提交 pull request 请求合并到 master 分支;
  4. 相关负责人 code review 后如果同意合并后,删除远程 feature 分支,如果不同意,重新修改后再上传 feature 分支请求 pull request。

发布流程

  1. 确保所有要发布的 pull request 已经 merge 到 master;
  2. 使用 master branch 的代码进行测试,如果发现 bug,把对应的 bugfix merge 到 master;
  3. 从 master 分支 git cherry-pick 过来新功能的 commit或者直接从 master 拉出(具体取决于 master 分支是否有不在本次 release 的commit, 如果没有,直接 merge, 如果有,就 cherry-commit);
  4. 测试并发布 release;
  5. 发布完成后打上版本 tag。

Bugfix 流程

这里的 bugfix 指的是修复已经发布的程序(release branch)中的缺陷。master 里的 bug 请直接 merge bugfix 到 master。

如果发现 bug,请先提交到工单系统。

  1. 如果此缺陷在 master 中还存在,请先 merge bugfix 到 master,否则跳到下一步;
  2. 在 release branch 从 master cherrypick 修复该缺陷的一个或多个 commit;
  3. 发布当前 release branch;
  4. 发布完成后在当前的 release branch 打上递增的 tag。

参考文档