1.分支说明
1.1 分支命名规范
| 名称 | 命名规则 | 说明 |
|---|---|---|
| main/master | 稳定版本,master已经不建议使用，使用main | |
| develop | dev/develop | 最新版本 |
| release | release/创建时间（YYYYMMDD） | 发布新版本 |
| feature | feature/功能点名称 | 实现新特性 |
| hotfix | hotfix/缺陷编号 | 修复线上紧急Bug |
| bugfix | bugfix/缺陷编号 | 修复普通Bug |
1.2 分支详细说明
| 分支名称 | 描述 |
|---|---|
| main | 主分支，负责记录上线版本的迭代，该分支代码与线上代码是完全一致的。研发负责人在Gitlab系统中设置main分支为protectd分支(保护分支)。protected分支不允许Developer推送代码，但 Maintainer可以推送代码。 |
| develop | 开发分支，该分支记录相对稳定的版本，所有的feature分支和hotfix分支都从该分支创建。研 发负责人在Gitlab系统中设置develop分支为protectd分支(保护分支)。 |
| release | 发布分支，用于代码上线准备，该分支从develop分支创建，创建之后由测试人员发布到测试环境 进行测试，测试过程中发现bug需要开发人员在该release分支上进行bug修复，修复完成自测没问题后，在上线之前，需要合并该release分支到master分支，同时需要再合并该分支到develop分支。 |
| feature | 特性（功能）分支，用于开发某个特定的功能，该分支从develop分支创建，不同的功能创建不同 的功能分支，开发完成自测没问题后，需要合并该分支到develop分支，之后删除该分支。 |
| bugfix | bug修复分支，用于修复某个普通的bug，该分支从develop分支创建，修复完成自测没问题后， 需要合并该分支到develop分支，之后删除该分支。 |
| hotfix | 热修复分支，用于修复某个紧急的bug，该分支只有在紧急情况下使用，该分支从master分支创 建，用于紧急修复线上的bug，修复完成自测没问题后，需要合并该分支到master分支，以便上线，同时需要再合并该分支到develop分支，之后删除该分支。 |
1.3 版本号说明
版本号为三位以"."分割的数字组成。第一个数字是主版本。第二个数字是次版本。第三个数字是补丁版本(hotfix类的更新)。
| 版本 | 说明 |
|---|---|
| 主版本 | 含有破坏性更新、大调整等。例如：1.0.0>2.0.0 |
| 次版本 | 增加新功能特性。例如：2.0.0>2.1.0 |
| 补丁版本 | 修复问题等。例如：2.1.0>2.1.1 |
2. 分支代码提交规范
2.1 提交用户设置
设置提交代码的用户名称和邮箱为本人姓名拼音和工作邮箱（{姓名拼音}@xx.com）。
如：张三 [email protected]
2.2 标题规范
提交规范一般包括：标题（类型、精简总结）、内容、备注。其中精简总结和类型是必填的，其余都是选填
| 名称 | 命名规则 |
|---|---|
| feat | 新功能 |
| fix | 修复bug |
| docs | 文档变更 |
| style | 代码格式优化 |
| refactor | 重构代码 |
| perf | 性能、页面优化 |
| test | 增加测试用例、单元测试 |
| revert | 回退版本 |
| build | 打包 |
| chore | 构建过程或辅助工具的变动 |
示例：feat:新增了某某参数校验功能
2.3 内容规范
内容主要填写详细的改动内容。如果精简总结写的比较完美，内容不写也是没关系。如果更改确实很多，并且时间充裕的话，把本次提交内容的实现、需求以及背景都填写，是很负责的做法。比如：
fix:修复了某某功能
此次更改了接口的逻辑判定，在请求中......增加了......优化......。