Git commit与分支命名规范
背景
创建分支和提交代码注释中关联需求或任务信息，是目前众多大厂以及许多开源项目的基本规范。我们工作室现目前在使用git上分支区分不清晰，commit信息较为随意，并没有很好的利用git做到版本管理。我们希望能通过良好的规范清晰展示代码修改的内容，同时可以帮助团队缩短解决问题的时间（快速回溯需求到代码）
目标
- 对不同名称分支的功能做到清晰分工
- 对commit格式和内容作出一定程度的规范，保证通过commit信息能清晰看到对代码的哪些部分进行了修改
具体规范
分支规范
- master：主分支，永远是可用的、稳定的、可直接发布的版本，不能直接在该分支上开发
- dev：开发主分支，该分支只做合并操作，不能直接在该分支上开发
- feature-xxx（feature/xxx）：功能开发分支，在master上创建分支，以开发功能命名完成后合并到develop分支
- hotfix-xxx（或hotfix/xxx）：紧急bug修改分支，项目上线之后可能会遇到一些环境问题需要紧急修复，流程跟release分支相似，修复完成要上线时合并master分支
commit规范
commit message需要包括两部分内容：header和body
- header（推荐）：简要描述此次commit的改动范围/内容
- body（可选）：若代码出现较大改变时填写
header
header部分只有一行，包括三个字段：
<type>(<scope>):<subject>
type：说明commit类型，只允许使用以下标识
- breaking：不兼容的改动，接口删除、数据库字段更新等，具体不兼容的部分用scope说明
- feat：新功能(feature)
- fix：修复bug
- perf：优化（包括提升性能、体验）
- refactor：重构（不是新增功能，也不是修改bug的代码改动）
- docs：文档调整(documentation)
- style：格式调整
- test：测试调整（增加测试用例等）
- chore：构建过程或辅助工具的变动
- revert：回滚到某个版本
scope：说明commit更改的文件名，多个用“,”分开
subject：commit简短描述（中文描述即可）
引用：cqupt蓝山工作室后端组文档