最近在实习，写了一个小需求。本地调试没问题后，提交代码，发现一直有两个错误：
subject may not be empty [subject-empty]
type may not be empty [type-empty]
Mentor 指出，是我提交时的 Commit Message 不规范造成的。
后来自己学习了一下 Commit Message 规范，记录成此笔记，若有不妥之处，欢迎批评指出～
1. Commit Message 组成
按照业界流行的
Conventional Commits
的相关规定，一个 Commit Message 的格式如下：
<type>(<scope>): <subject>
[optional body]
[optional footer(s)]
整体的格式：
- 包含三个部分：Header、Body、Footer
- 其中，Header 是必需的，而 Body 和 Footer 可选
-
每个部分之间有一个
空行
- 每行内容长度不能超过 100 个字符
2. 每部分规范说明
1. Header（必写）
<type>(<scope>): <subject>
注意：冒号
:
和
<subject>
之间有一个
空格
。
（1）type
必填项，表示本次改动的提交类型，包括的类型有：
-
build
：影响内部依赖和构建的修改，例如 glup，webpack，rollup 的配置等。 -
chore
：其他不修改
src
或
test
文件的更改。 -
ci
：更改
CI
的配置文件。 -
docs
：文档更新。 -
feat
：添加新功能。 -
fix
：修复代码库的 Bug。 -
perf
：提升性能的更改。 -
refactor
：代码重构，没有设计修改 Bug 和新加功能。 -
revert
：回滚到某个 commit 的提交。 -
style
：格式修改，不涉及程序逻辑。 -
test
：涉及测试用例的修改。
（2）scope
非必填，用于描述改动的影响范围，格式为
项目名/模块名
，标识此次提交主要涉及到代码中哪个模块。
（3）subject
必填项，此次提交的
描述内容
，语语句尽量简短。
-
以动词原型开头，比如
change
，而不是
changes
- 第一个字母小写
-
结尾不加句号
.
2. Body（可选）
Body 部分是针对本次 commit 的
详细描述
，内容较长时，要进行合理的换行，要表达清楚变动的动机以及与之前行为的对比。好的提交信息要回答下面的内容：
- 为什么要提交这次修改？
- 怎么解决的问题？
- 可能影响哪些内容？
如果在 Body 上需要附上相关链接，则
ref: url
。
3. Footer（可选）
Footer 部分只用于两种情况：
- BREAKING CHANGE（不兼容变动）
- 关闭 Issue
3. 一些 Commit 举例
都省略了 Body 和 Footer。
chore: run tests on travis ci
fix(server): send cors headers
feat(blog): add comment section
4. 使用 commitlint 进行规范检查
commitlint 可以检查 Commit Message 是否符合
Conventional Commits
的格式。
详情配置见
commitlint
。
参考：
📘📘欢迎在我的博客上访问：
https://lzxjack.top/