Git提交规范
一、背景
统一git提交的信息，方便快速定位问题，提交美观。
二、git commit 规范说明
Git 提交规范，具有参考价值的就是Angular的提交，该规范将commit分为若干个类型，根据提交的代码功能分为以下类型。
2.1 基本commit类型
2.1.1 type(必填)
用于说明本次commit的类别，只允许使用下面7个标识
feat：新功能（feature）fix：修补bug（描述可以是问题号+问题描述）docs：文档（documentation）chore：其他
基本上我们在日常开发中使用的最多的都是feat以及fix。
2.1.2 scope(必填)
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
例如在Angular，可以是location，browser，compile，compile，rootScope， ngHref，ngClick，ngView等。如果你的修改影响了不止一个scope，你可以使用*代替。
当前影响改为具体页面、具体功能的影响
feat(home)：修改首页布局
fix(login): #676 修复登录bug，解决方式：增加登录判断逻辑2.1.3 subject(必填)
subject是commit目的的简短描述，不超过50个字符。
建议使用中文（感觉中国人用中文描述问题能更清楚一些）。
结尾不加句号或其他标点符号。
根据以上规范git commit message将是如下的格式：
功能提交模板：
feat:title:TB task name
content: detail xxxxxxx
bug fix模板：
fix：禅道id 禅道title #676 修复强制更新问题
原因：
解决方案：
doc/chore：
content：xxxx2.2 基本写法事例
git add .
git commit -m "feat: 完成强制更新功能"
git commit -m "fix: 强制更新弹窗bug"
git commit -m "fix: #352 强制更新弹窗bug"
git commit -m "fix: 删除功能页面下的ForceUpdate.tsx文件"
git commit -m "style: 代码格式化"
git commit -m "chore: 增加打包脚本"
git commit -m "docs: 增加项目文档"2.3 idea、vscode、android studio的插件使用
以上的规范在常用的编辑器中都有插件支持，可以在应用市场直接搜索。
2.3.1 idea、android studio插件安装
1）打开插件中心
2）搜索git commit template插件并安装
3）使用打开侧边commit tab
插件提供了type、scope、message的信息填写。
2.3.2 vscode插件安装
应用市场搜索 commit message Editor 安装
三、git 分支规范
现在常用的git flow规范
3.1 分支说明
| 分支 | 分支名称 | 备注 |
|---|---|---|
| master/main | 主分支 | |
| dev/develop | 开发分支 | |
| feat/feature | 需求功能分支 | |
| fix/hotfix | 紧急修复分支 | |
| release | 预上线分支 |
3.1.1 master 分支
master 为主分支，用于部署到正式环境（PRO），一般由 release 或 hotfix 分支合并，任何情况下不允许直接在 master 分支上修改代码。
3.1.2 release 分支（非必需）
release 为预上线分支，用于部署到预上线环境（UAT），始终保持与 master 分支一致，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。
3.1.3 hotfix 分支（非必需）
hotfix 为紧急修复分支，命名规则为 hotfix- 开头。当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。
3.1.4 dev 分支
dev 为测试分支，用于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由 feat 分支合并，还是直接在上面开发。
一定是满足测试的代码才能往上面合并或提交。
3.1.5 feat 分支
fea 为需求开发分支，命名规则为 feat- 开头，一旦该需求上线，便将其删除。
这么说可能有点不容易理解，接下来举几个开发场景。
3.3 分支命名规范
3.3.1 feat 分支命名规范
格式: feat/功能-tb任务id-工号
tb 的任务 id 如下：
例如：feat/人脸识别-256-zjth2015
3.3.2 fix 分支命名规范
格式：fix/bug修复-禅道id-工号
禅道 id 如下
四、项目限制
为规范所有开发成员的提交，可以通过利用git hook事件限制提交，前端项目可以通过 npm包@commitlint/cli @commitlint/config-conventional husky 来限制不规范commit提交；后台以及app端项目需要使用脚本动态添加到.git/hooks/目录中提交事件限制提交。
https://github.com/tapsellorg/conventional-commits-git-hook/blob/master/commit-msg-hook.sh