规范的 Git Commit 信息的重要性

在开发中当完成了代码的开发和自测，准备提交 MR（或 PR）时，我们要做的是提交自己的代码，无论使用何种版本管理工具，代码提交说明总是少不了的。

为什么重要

提交说明需要清晰易懂，同时也要高度概括此次提交中所做的事情。项目发展到一定程度后积累的提交数量是巨大的，没有规范化的提交说明将难以阅读，最终影响到开发效率。

在进行项目维护时也许我们能看到下面这样的提交说明：

1. fix few err
2. convert string to int

这两个提交说明要么太过于概括，要么太过于具体，我们无法从描述中知道改动哪个功能/模块，更没法知道具体修复的什么 bug，原因是什么。

如何书写规范的提交说明

所谓规范肯定是经历过时间考验，被大多数人认同，归纳总结得来的。 但选用规范时仍要根据自己的情况出发选择合适的，毕竟规范的维护也是有成本的。

1. 语义化的，可以被机器识别。

语义化：
编译原理编译器编译源码时有一步叫语义分析，用于检查是否使用未声明的变量，类型是否正确等。例子：angular 提交记录里 #42870 会被链接到一个 PR，就是因为被程序检查出来这个数字的语义是：提交对应 PR 的编号为 42870。

可被机器识别的话就可以做很多事情了：

• 可以触发构建或发布流程，比如识别到提交会修改代码时触发构建流程，如果只是文档修改则不需要构建。
• 可以自动生成 ChangeLog。

2. 高度概括的同时陈述重点。

提交说明应该包括 涉及的模块/功能，以及对其 做了什么样的改动。

Angular 的提交规范

Angular 规范是目前用得最多的，语义化的提交规范。

先看一个遵循 Augular 规范的提交记录。

image.png

下面是一个完整的提交说明：

怎么写出符合 Angular 规范的 Git Commit 信息

在 Angular 规范中，提交说明包含三个部分，分别是 Header、Body 和 Footer，格式如下：

[optional scope]: 
// 空行
[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 列表。

自动化支持

1. commitizen-go: 在终端中进入交互模式生成 Commit Message。
2. go-gitlint: 检查 Commit Message 是否符合 Angular 规范。
3. git-chglog: 根据 Commit Message 生成 Change Log。