规范设计：Commit Message 规范

Commit Message 规范

使用规范的Commit Message的好处：

使自己和其他开发人员清晰地知道每个commit的变更内容，方便快速浏览变更历史。
方便进行过滤查找，比如查找某个版本新增的功能：git log --oneline --grep "^feat|^fix|^perf"
方便生成Change Log
可以依据某些类型的Commit Message触发构建或者发布流程，比如当type类型为feat、fix时触发CI流程
方便确定语义化版本号（如果对语义化版本号不了解，可以查看我的上一篇文章：《项目中的规范：语义化版本规范》），比如fix 类型的 commit 可以将修订号 +1

目前有多种流行的Commit Message规范，下文将介绍使用的最多的Angular规范。

Angular规范标准格式

标准格式

<type>(<scope>): <subject> #header
// 空一行
<body>
// 空一行
<footer>

Header 是必需的，Body 和 Footer 可以省略。

Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
type
用于说明本次commit的类别，只允许使用下面的标识：

feat: 新增功能（feature）
fix：Bug修复
perf：提高代码性能的变更
style：代码格式类的变更，即：不会影响代码含义的更改（空格，格式，缺少分号等）
refactor：重构（不属于feat、fix、perf、style的变更），例如：简化代码、重命名变量、删除冗余代码等
test：添加缺失的测试或更正现有的测试
ci：对CI和部署相关的改动，例如新增或修改CI配置文件或脚本
docs：文档类的更新
chore：其他类型的更新，比如构建过程、依赖管理或辅助工具的变动

scope
用于说明 commit 影响的范围，必须是名词，比如数据层、控制层、视图层等等，视项目不同而不同。
需要注意的是，scope不适合设置太具体的值（即粒度很小的scope），原因是：

太具体的scope会导致项目有太多的scope，难以维护。
太具体的scope会让开发者难以确定有些commit属于哪个具体的scope，导致错放scope，使scope失去分类的意义。

subject
是 commit 目的的简短描述，不超过50个字符。
要求如下：

以动词开头，使用第一人称现在时，比如change，而不是changed或changes
第一个字母小写
结尾不加句号（.）

Body部分

Body部分是对本次commit的详细描述，但它是可选的。
Body部分格式自由，但一般以动词开头，使用现在时，内容包括修改动机，以及跟上一版本相比的改动点。

Footer部分也是可选的，通常用来说明不兼容的改动和关闭Issue
不兼容的改动
如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。
例：

BREAKING CHANGE: isolate scope bindings definition has changed.

To migrate the code follow the example below:

Before:

scope: {
  myAttr: 'attribute',
}

After:

scope: {
  myAttr: '@',
}

The removed `inject` wasn't generaly useful for directives so there should be no code using it.

关闭 Issue
如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。
例：

# 一次关闭一个issue
Closes #234

# 一次关闭多个issue
Closes #123, #245, #992

Commit Message的特殊情况：Revert Commit

如果当前 commit 欢迎了以前的 commit，则必须以revert:开头，后面跟着被撤销 Commit 的 Header，而且Body中必须写成This reverts commit <要还原的commit的hash值>
例：

1
2
3

revert: feat(pencil): add 'graphiteWidth' option

This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

Peter's Blog