在开发中当完成了代码的开发和自测，准备提交 MR（或 PR）时，我们要做的是提交自己的代码，无论使用何种版本管理工具，代码提交说明总是少不了的。
为什么重要
提交说明需要清晰易懂，同时也要高度概括此次提交中所做的事情。项目发展到一定程度后积累的提交数量是巨大的，没有规范化的提交说明将难以阅读，最终影响到开发效率。
在进行项目维护时也许我们能看到下面这样的提交说明：
- fix few err
- convert string to int
这两个提交说明要么太过于概括，要么太过于具体，我们无法从描述中知道改动哪个功能/模块，更没法知道具体修复的什么 bug，原因是什么。
如何书写规范的提交说明
所谓规范肯定是经历过时间考验，被大多数人认同，归纳总结得来的。 但选用规范时仍要根据自己的情况出发选择合适的，毕竟规范的维护也是有成本的。
- 语义化的，可以被机器识别。
语义化：
编译原理编译器编译源码时有一步叫语义分析，用于检查是否使用未声明的变量，类型是否正确等。例子：angular 提交记录里 #42870 会被链接到一个 PR，就是因为被程序检查出来这个数字的语义是：提交对应 PR 的编号为 42870。
可被机器识别的话就可以做很多事情了：
- 可以触发构建或发布流程，比如识别到提交会修改代码时触发构建流程，如果只是文档修改则不需要构建。
- 可以自动生成 ChangeLog。
- 高度概括的同时陈述重点。
提交说明应该包括 涉及的模块/功能，以及对其 做了什么样的改动。
Angular 的提交规范
Angular 规范是目前用得最多的，语义化的提交规范。
先看一个遵循 Augular 规范的提交记录。
image.png
下面是一个完整的提交说明：
怎么写出符合 Angular 规范的 Git Commit 信息
在 Angular 规范中，提交说明包含三个部分，分别是 Header、Body 和 Footer，格式如下：
<type>[optional scope]: <description>
// 空行
[optional body]
// 空行
[optional footer(s)]
其中，Header 是必需的，Body 和 Footer 可以省略。
Header
Header 部分只有一行，包括三个字段：type（必选）、scope（可选）和 subject（必选）。
type 的定义是灵活的，只要保证在一个项目中的一致就可以。下面的图片整理了常见的 type 以及如何选用。
image.png
scope 是用来说明 commit 的影响范围的，不同项目会不同。scope 可以按功能、组件进行划分。需要注意的是 scope 划分不能太细也不能太宽泛，要根据项目的复杂程度进行划分。
subject 是 commit 的简短描述，必须以动词开头，应该描述清楚对哪些模块/功能做了什么样的改动。
Body
subject 对 commit 做了高度概括，可以方便我们维护时查看。但如果需要更多的细节怎么办？可以通过 Body 部分，它是对本次 commit 的更详细描述，是可选的。
可以在其中说明修改的原因，需要的话列出改动点。
Footer
Footer 是可选的，有不兼容改动时可在 Footer 中列出不兼容的内容及其替代。或是关闭的 Issue 列表。
自动化支持
- commitizen-go: 在终端中进入交互模式生成 Commit Message。
- go-gitlint: 检查 Commit Message 是否符合 Angular 规范。
- git-chglog: 根据 Commit Message 生成 Change Log。
网友评论