Git commit 提交的内容竟然还有规范，你知道吗？

微信公众号：后端早读课

有些人喜欢在 commit 里面写 「feat: 新增用户数据获取接口」，
也有些人在 commit 只写一个 「fixbug」 而不知所云，
更有人喜欢在 commit 写首唐诗来表达工作结束的心情，
有些人提交 MR 后，活得更好了，
而有些人提交 MR 后，死了。

Conventional Commits 是由众多开源项目贡献者共同约定的一个规范，用来约定 Git Commit 内容的书写方式，让 commit 内容更有价值、条理，使提交历史明确可追溯。

简单的结构化

<type>[optional scope]: <description>
​
[optional body]
​
[optional footer(s)]
复制代码

• type : 类型，比如 feat 代表 feature，如果有新功能，则使用 feat:
• scope: (可选) 范围，主要是此次修改的领域，比如 pharse，但是需要使用括号包裹起来，比如 fix(pharse):
• description: 一个简短的描述这次修改的内容
• body: (可选) 具体的描述本次修改的内容正文，可以是多行，虽然是想写什么写什么，但是也要抓重点。
• footer: (可选) 本次修改的脚注，针对重大修改使用「BREAKING CHANGE: 」来标记。

（如果没有特别说明，所有的「:」冒号后面都要加「空格」， :<space>）

规范只明确约定了两种提交类型 feat: 和 fix:

• feat: 主要用于新增的功能（new feature）。
• fix: 主要用于修复 Bug。

footer 脚注中可以使用「BREAKING CHANGE: 」来描述「破坏性改变」的重要变更。

如果修改的内容属于重要变更，但是有没有什么可说的，所谓：字少事大。那么可以通过在 type 的后面，冒号的前面增加 「!」感叹号来表示，比如

feat: 修改了 API 协议
​
增加了很多不可描述的事情
删除了一些不必要的参数
​
BREAKING CHANGE: 修改了 API 协议
复制代码

可以简化成

feat!: 修改了 API 协议
​
增加了很多不可描述的事情
删除了一些不必要的参数
复制代码

或者可以再增加 scope 的内容

feat(protocol)!: 修改了 API 协议增
​
加了很多不可描述的事情
删除了一些不必要的参数
复制代码

footer 的书写规范有些意思，它有自己的数据格式，比如

<Word-token>:<space><value>
<Word-token><space>#<value>
复制代码

其中，key（word token) 中如果有「空格」，需要替换成「-」(word-token)，而这样做的理由就是为了和 body 正文中内容的进行区分。

但是 「BREAKING CHANGE:」这个关键词是不遵守上面约定的，空格不必换成「-」，不过万一写成了「BREAKING-CHANGE」，这样也等同于「BREAKING CHANGE」。

除了 「BREAKING CHANGE:」外，还可以写

Reviewed-by: Z
Refs #133
复制代码

之类的自定义的内容。

以上是规范约定的内容，不仅言简意赅。同时通过约定，还可以通过自动化工具直接生成 SemVer 版本号 （MAJOR.MINOR.PATCH）。

其中 feat: 提交会增加 MINOR 版本号， fix: 提交会增加 PATCH 版本号，而带有 「BREAKING CHANGE: 」脚注或者在 type 后面含有「!」 的 提交，会增加 MAJOR 版本号。

根据规范，各团队可以定制自己的自动化策略，比如测试、构建、部署等流程。

不过，虽然规范约定了 feat 和 fix 类型，但是其也表示了各团队可以根据各自需要来增加类型，比如 docs: 、style: 、chore: 之类。甚至还可以使用 emoji （可以参考 lerna 中的提交规范）

你瞧，Conventional Commits 不仅约定了一个很好的规范，还提供了可扩展性，这不比自己绞尽脑汁瞎写 log 要强多了？

Bad case:

fix a bug
复制代码

Good case:

fix: 修复了由于宇宙射线引起的服务不稳定问题
​
狮子座流星雨放出了很多神秘射线，导致对账误差过大
​
Sentry #2021
复制代码

请让我们的每一次提交变得有意义吧~