提交规范有什么用
- 当你想寻找之前的一次提交记录，想复现问题的时候
- 当你不想一个一个翻，寻找提交文件看的某次修改或者破坏性修改的时候
提交规范将会带给你便利
我还是比较有代码洁癖的，每一次提交都只做一个功能的修改或者开发，这样很方便后续根据记录回顾或寻找问题
格式
<type>[scope]: <subject>
# 空行
[optional body]
# 空行
[optional footer]
<>：必填[]：选填
type（必填）
feat新功能：新需求的实现fix修复：对bug的修复docs文档：描述文档的变更style代码风格：对代码风格的修改 格式化refactor重构代码：对代码进行重构 结构调整perf代码性能：提高代码性能的改变test测试：测试相关的提交build影响构建系统或外部依赖项的更改：maven、gradle、npm等chore构建过程或辅助工具的变动：比如之前用maven，后面换成了Gradlerevertrevert a commit 撤销提交
type会让此次提交的目的一目了然，必填
scope（选填）
可以写明影响的是哪个模块(module name) 或者是哪个层（视图层、服务层、持久层）
用来表明此次提交影响的范围，便于定位，就不用去看提交的文件了
subject / short description（必填）
简短的描述此次代码变更的主要内容
body / long description（选填）
比较详细的描述本次提交设计的内容，罗列代码功能，可以用markdown语法
如果subject可以描述清楚的话，就不用填body
break change
指明本次提交是否产生了破坏性的修改，类似版本升级、接口参数减少、接口删除、迁移等
如果产生了类似的破坏性影响，建议在提交信息中写明break change
close issues
关联本次提交涉及的issue，可以是需求号或者BUG号，或word标题
视公司情况而定
