分支开发规范

为了更好的对项目研发流程进行标准化管理，提高整体研发效率，本文档对日常开发过程中的代码管理、分支命名以及分支使用等环节做了基本约定，确保分支管理的规范化和标准化，本文适用于所有团队的各种不同分支管理情况。

该部分给出正常的研发流程，无特殊情况，研发流程均已该方式执行。

该方式采用分支开发，每位开发人员开发前，从 Master 拉取开发分支，进行功能性开发，在分支阶段完成各项流程后，合并到 Master 分支。上线阶段通过 Master 发布 Release tag 版本，用于线上部署。该部分规范为：

【强制】 项目开发采用分支开发方式，新需求开发前，从 Master 拉取分支；

【建议】开发分支在完成测试工作、CR 通过后，在上线当天方可合并到 Master。

【建议】上线分支使用基于 Master 创建 release版本，正常情况下，release 版本禁止修改。

【建议】代码发起 PR 时，需先同步 master。

该部分给出了在开发过程中，对于代码仓库管理的一系列标准和约束，从而保证代码的可维护性和可迭代。该部分包含了以下几个约束条件。

【强制】 除特殊平台外，线上使用代码一律采用 git 管理。

【强制】 线上代码仓库需设置至少两名管理员。

【强制】 对于线上服务代码，禁止使用个人仓库管理。

【强制】 线上代码仓库，必须设置禁止直接提交 Master。

【强制】 创建仓库组需给出合理的理由，项目涉及的范围至少是部门级别。

【强制】 创建仓库组由负责人提出需求给部门TC委员，由TC委员在 TC 层面发起审核，审核通过后联系质效部创建（无TC成员的部门可以提交给对应部门的X3）。

【建议】仓库组名称最好体现团队组织，不能过于宽泛，建议采用组织缩写前缀，描述信息需要描述清楚所属团队，功能信息。

【建议】对于通用的基础库代码，如日志，监控等，建议仓库设置成 public。

【建议】线上代码仓库组的命名，建议采用组织或者业务线命名；

【强制】 主干分支的回退应该使用 git revert 的方式，不应该通过 push -f 的方式；

【强制】 合并本地多个 commit， 本地提交可能有多个 commit，建议再推送到远端之前合并这些 commit，并且根据 commit 的消息格式要求，填写规范的 commit 消息；

【建议】提交代码时，建议不要使用 git amend 、git rebase 等命令；

【建议】对于周期长的项目，不建议频繁push到远端，push 到远端后不建议执行 push -f 操作。

在项目开发阶段，项目分支分为集成分支和开发分支两类，其中集成分支用于自动化系统相关操作使用的分支，开发分支为开发人员使用分支。在开发过程中，开发人员需遵守相应的分支命名，避免分支误用，其具体要求如下：

【强制】 项目功能需求，开发分支命名采用feature 开头方式，如 feature-XX、feature/XX，不区分大小写。

【强制】 BUG 修复需求，开发分支命名采用 bugfix 开头方式，如 bugfix-XX、bugfix/XX，不区分大小写。

【强制】 需上线的开发分支不能用以下名称命名，以下名称命名的开发分支不会被统计到分支相关指标中：

【建议】开发分支建议在 Ones 中创建，开发环境直接拉取的方式，该方式创建的分支会直接遵守上述命名方式命名，同时会直接和 Ones 需求关联。

分支管理方面对开发人员同时进行一个或多个项目的开发进行了规范，保证不同需求项目间的协作，提高研发效率和研发质量，其约束如下：

【强制】 开发分支必须关联对应的交付单元；

【强制】 若开发分支为 bugfix 分支，则必须关联缺陷任务；

【强制】 对于同时开发多个项目人员，必须一个项目创建一个分支，禁止分支复用。

【建议】多人开发一个项目，每个 RD 创建一个任务，每个交付单元创建一个开发分支。

对于研发规范的约束，我们将从工具层面进行强制卡控，保证规范的实施。