分支命名规范

目录

• 开发过程常用的环境
• 分支
  • 基本了解
  • 分支作用
    • master
    • release
    • hotfix
    • develop
    • feature
  • 开发场景
    • 新需求加入
    • 普通迭代
    • 修复测试bug
    • 修复预上线bug
    • 修复正式环境bug
    • 紧急修复正式环境bug
    • 并行提测
• commit提交规范

开发过程常用的环境

简称	全称	解析	域名
DEV	Devlopment environment	开发者调试使用	本地配置虚拟域名即可
FAT	Feature Acceptance Test environment	功能验收测试环境	http://fat.abc.com
UAT	User Acceptance Test environment	用户验收测试环境	http://uat.abc.com
PRO	Production environment	生产环境	http://www.abc.com

分支

基本了解

分支	名称	环境	可访问
master	主分支	PRO	是
release	预上线分支	UAT	是
hotfix	紧急修复分支	DEV	否
develop	测试分支	FAT	是
feature	需求开发分支	DEV	否

分支作用

master

1. master为主分支，用于部署到正式环境(PRO)，一般有 release 或hotifx分支合并。
2. 任何情况下不允许在 master 分支上修改代码。

release

1. release为预上线分支，用户部署到预上线环境(UAT)，始终保持与master分支一致，一般由 develop 或 hotfix 分支合并。
2. 不建议直接在 release 分支上修改代码。
3. 如果在release分支上测试出现问题，需要回归验证 develop 分支是否存在此问题。

hotfix

1. hotfix为紧急修复分支，命名规则为 hotfix/ 开头。
2. 当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。

develop

1. develop 为测试分支，用于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发。
2. 一定是满足测试的代码才能往上面合并或提交。

feature

1. feature 为需求开发分支，命名规则为 feature/ 开头，一旦该需求上线，便将其删除。

代码变更仅允许在feature和hotfix分支进行操作，其他分支变更均由分支操作导致变更

开发场景

新需求加入

1. 有一个订单管理的新需求需要开发，首先要创建一个 feature-order 分支，问题来了，该分支是基于哪个分支创建？

   如果 存在 未测试完毕的需求，就基于 master 创建。
   如果 不存在 未测试完毕的需求，就基于 develop 创建。

2. 需求在 feature-order 分支开发完毕，准备提测时，要先确定 develop 不存在未测试完毕的需求，这时研发人员才能将将代码合并到 develop （测试环境）供测试人员测试。

3. 测试人员在 develop （测试环境） 测试通过后，研发人员再将代码发布到 release （预上线环境）供测试人员测试。

4. 测试人员在 release （预上线环境）测试通过后，研发人员再将代码发布到 master （正式环境）供测试人员测试。

5. 测试人员在 master (正式环境) 测试通过后，研发人员需要删除 feature-order 分支。

普通迭代

1. 有一个订单管理的迭代需求

   如果开发工时 < 1d，直接在 develop 开发。
   如果开发工时 > 1d，那就需要创建分支，在分支上开发。

2. 开发后的提测上线流程 与 新需求加入的流程一致。

修复测试bug

1. 在 develop 测试出现了Bug

   如果修复工时 < 2h，直接在 develop 修复。
   如果修复工时 > 2h，需要在分支上修复。

2. 修复后的提测上线流程 与 新需求加入的流程一致。

修复预上线bug

1. 在 release 测试出现了Bug，首先要回归下 develop 分支是否同样存在这个问题。

   如果存在，修复流程 与 修复测试环境 Bug流程一致。
   如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。

修复正式环境bug

1. 在 master 测试出现了Bug，首先要回归下 release 和 develop 分支是否同样存在这个问题。

   如果存在，修复流程 与 修复测试环境 Bug流程一致。
   如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等。

紧急修复正式环境bug

1. 需求在测试环节未测试出 Bug，上线运行一段时候后出现了 Bug，需要紧急修复的。
   我个人理解紧急修复的意思是没时间验证测试环境了，但还是建议验证下预上线环境。

2. 如果 release 分支存在未测试完毕的需求，就基于 master 创建 hotfix-xxx 分支，修复完毕后发布到 master 验证，验证完毕后，将 master 代码合并到 release 和 develop 分支，同时删掉 hotfix-xxx 分支。

3. 如果 release 分支不存在未测试完毕的需求，但 develop 分支存在未测试完毕的需求，就基于 release 创建 hotfix-xxx 分支，修复完毕后发布到 release 验证，后面流程与上线流程一致，验证完毕后，将 master 代码合并到 develop 分支，同时删掉 hotfix-xxx 分支。

4. 如果 release 和 develop 分支都不存在未测试完毕的需求， 就直接在 develop 分支上修复完毕后，发布到 release 验证，后面流程与上线流程一致。

并行提测

1. 在一个项目中并行开发了两个需求，并行提测，但是上线日期不同。
2. 可使用的方案为：
   1. 再部署一套可供测试人员测试的分支
   2. 使用 git cherry-pick “挑拣”提交

commit提交规范

1. 提交信息一定要认真填写！

   在多人协作项目中，如果代码风格统一、代码提交信息的说明准确，那么在后期协作以及Bug处理时会更加方便。

2. 建议参考规范：(scope)：

   比如：fix(首页模块)：修复弹窗 JS Bug。

   1. type 表示 动作类型，可分为：
      • fix：修复 xxx Bug
      • feat：新增 xxx 功能(feature)
      • test：调试 xxx 功能
      • style：变更 xxx 代码格式或注释
      • docs：变更 xxx 文档(documentions)
      • refactor：重构 xxx 功能或方法
   2. scope 表示 影响范围，可分为：模块、类库、方法等。
   3. subject 表示 简短描述，最好不要超过 60 个字，如果有相关 Bug 的 Jira 号，建议在描述中加上。

   fix用于feature和hotfix分支使用，即用于DEV环境使用（bug修复）
   feat用于feature分支使用，即用于DEV环境使用（新增功能）
   test用于hotfix分支使用，即PRO，UAT和FAT环境使用（测试与调试）
   style用于feature分支使用，即DEV环境使用（代码风格变更）
   docs用于feature分支使用，即DEV环境使用（新增功能文档）
   refactor用于hotfix分支使用，即DEV环境使用（功能或方法重写）