规范梳理
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
type(必须)
feat
功能feature
的意思,也是最常用的。当你的功能有变更的时候,都可以采用这种类型的typefix
当然指的是bug修复docs
更新了文档,或者更新了注释style
代码格式调整,比如执行了format、更改了tab显示等refactor
重构代码。指的是代码结构的调整,比如使用了一些设计模式重新组织了代码perf
对项目或者模块进行了性能优化。比如一些jvm的参数改动,把stringbuffer改为stringbuilder等test
这个简单,就是增加了单元测试和自动化相关的代码build
影响编译的一些更改,比如更改了maven插件、增加了npm的过程等ci
持续集成方面的更改。现在有些build系统喜欢把ci功能使用yml描述。如有这种更改,建议使用cichore
其他改动。比如一些注释修改或者文件清理。不影响src和test代码文件的,都可以放在这里revert
回滚了一些前面的代码merge
代码合并sync
同步主线或分支的Bug
scope(可选)
scope是范围的意思,主要指的是代码的影响面。scope并没有要求强制,但团队可以按照自己的理解进行设计。通常由技术维度和业务维度两种划分方式。比如按照技术分为:controller
、dto
、service
、dao
等。但因为一个功能提交,会涉及到多个scope(都不喜欢非常细粒度的提交),所以按照技术维度分的情况比较少。
按照业务模块进行划分,也是比较不错的选择。比如分为user
、order
等划分,可以很容易看出是影响用户模块还是order模块。
如果你实在不知道怎么填,那就留空。
subject(必须)
这个体现的是总结概括能力,没得跑。一句话能够说明主要的提交是什么。subject也是众多git管理工具默认显示的一行。如果你写的标准,那么提交记录看起来就很漂亮很规整。
正文Body
主要填写详细的改动记录。一般习惯列上1234,但如果你的subject写的非常好,正文可以直接弱化。但如果时间充裕,填写上重要记录的前因后果,需求背景,是一个好的习惯。
尾部Footer
添加一些额外的hook,比如提交记录之后,自动关闭jira的工单(JIRA和gitlab等是可以联动的)。在比如触发一些文档编译或者其他动作。
这部分自定义行也是比较强的。
Skip CI
最后还有一个skip CI选项。一般的ci工具,都可以设置提交代码时自动触发编译。但你可以告诉它忽略本次提交。这可能是因为你提前预判到了一些构建风险,或者就是不想编译。
End
最后,看一个典型的提交记录,有了工具的支持,我们的瞎扯也看得正经起来。
fix(order): 修复了1分钱买汽车的bug
商务反馈可以1分钱买汽车,目前已经卖出了100w量
Closes #2455
[skip ci]