分支管理规范

概念介绍

设立 master、test、release、feature、personal、hotfix 分支

  1. master 分支是每个项目的主分支,属于绝对保证 pure 的分支,必须保证每行代码都是经过测试验收确认的分支。绝对一定必须肯定不能被污染。
  2. test 分支是项目测试分支。如果有项目并行测试问题,需测试人员负责跟各个项目负责人沟通确认测试分支的合并和提测。
  3. release 分支是项目的可提测和可上线分支。release 分支目前使用的比较弱,它的目的是解决master不能被污染的问题。但如果有预发布环境,则 release 分支作为预发布环境的代码分支。稍后会作详细介绍。
  4. feature 分支是项目迭代分支,每次项目迭代版本确定并进入开发阶段后,由项目负责人创立项目迭代分支(组分支)。项目结束后删除。
  5. personal 分支是项目成员的个人分支,由开发人员自行创立,不强制要求都设立个人分支。但推荐创建个人分支。项目结束后删除。
  6. hotfix 分支是项目上线后遇线上 bug 后,创建的热修复分支,由项目负责人创建并维护,修复完成并上线成功后删除。
    一般地,项目代码只有项目内开发人员有相应权限,项目外开发人员无任何权限(不做硬性要求,若开发需要或出于学习目的可以申请项目代码相应权限)。

一般地,master 分支、release 分支、test 分支、hotfix 分支由项目负责人负责维护;feature 分支、personal 分支由项目负责人和相应开发人员负责维护。

一般地,master 分支只有项目负责人有合并权限,开发人员有 checkout 的权限。release 分支由项目负责人、测试人员有合并权限(测试人员通过 gitlab 获得权限),开发人员有 checkout 权限但无合并权限。test 分支由项目负责人、测试人员有合并权限(测试人员通过 gitlab 获得权限),开发人员有 checkout 权限但无合并权限,只有项目负责人有删除权限。feature 分支由项目负责人、项目开发人员均有创建、提交、合并、拉取等权限,但只有项目负责人有删除权限。personal 分支开发人员有创建、提交、合并、拉取、删除的权限,项目负责人也有相同权限。

流程说明

  1. 项目开始,由项目负责人从 master 拉取代码到 release 和 test。注意这里,每次项目开始如无其他项目测试在进行,且经过测试人员确认同意后,可以删除 test 分支再重新从 master 上 checkout 出 test 分支。这样可以保证 test 分支每次都很干净纯粹,更专业讲叫保证分支 pure。而 release 分支一般不需要重新创建,只需要从 master 上惯性 merge 至 release 分支即可。图中1、2

  2. 同时项目负责人还需要创建项目分支,项目分支统一在 feature 文件夹下,项目分支的命名规则可以由各个项目负责人自行约定,这里不统一约定,推荐命名规则:项目名称_版本号。如:datawarehouse_v1.0.0 图中3

  3. 开发人员可以创建自己的个人分支,基于 feature 里面的项目迭代分支(组分支)创建。并在个人分支进行开发,开发完成后合并至 feature 的组分支。图中4、5

  4. 项目负责人确认项目完成开发和自测,可以提交测试后,跟测试人员商议确定可以合并至 test 后,合并 feature 里面的项目组分支到 test 分支,进入测试阶段。图中6

  5. 测试完成后,测试人员确认项目达到上线标准,由项目负责人合并 test 分支代码到 release 分支,再由 release 合并至 master 分支,进入上线阶段。 图中7、8

  6. 上线后如果有 bug,由项目负责人从 master 拉取 hotfix 分支修复 bug。hotfix 名称规范推荐:hotfix 主要 bug 名称_项目版本号. 图中9、10

  7. 测试完成验收后,由项目负责人将 hotfix 代码直接合并至 master 分支进行上线。图中11

  8. 同时,由项目负责人将 master 合并至 release 分支。但不强制要求。

以上流程讲解的就是一个项目迭代从开始进入开发阶段到上线完毕以及热修复结束的整个过程。

开发人员应尽量避免同一个项目不同功能迭代同时开发同时测试同时上线的问题,也尽量让产品、测试人员都意识到并行测试上线的风险(万一一个功能迭代项目存在上线不了的问题会导致另外的功能迭代项目在测试阶段的 test 分支代码污染等问题)。若不能避免,则按照我们会议上讨论的方案来执行:

  1. 由测试人员严格把控 test 分支的合并问题。

  2. 由项目负责人严格把控项目上线风险问题以及严格把控合并 test 分支的必要性。

  3. 若发生污染,则可以跟测试人员沟通确认后删除 test 分支,重新 checkout 出 test 分支,再对需要上线的项目进行合并,对上不了线的项目进行不予合并的处理。

  4. 再者,开发人员一定要注意各个分支的 checkout 和 merge 的方向性问题,分支从哪里切出,又往哪里合并,分支的生命周期等,都要根据上图中的严格执行,避免出错。

以上流程在会议中都经过开发人员、测试人员全体讨论最终确认,后续大家一起遵守规范,高效协作。