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

<type>[optional scope]: <description>
// 空行
[optional body]
// 空行
[optional footer(s)]

其中，Header 是必需的，Body和 Footer 可以省略。在以上规范中，scope 必须用括号 () 括起来， [] 后必须紧跟冒号，冒号后必须紧跟空格，2 个空行也是必需的。

在实际开发中，我们往往会限制每行 message 的长度。根据需要，可以限制为 50/72/100 个字符，

以下是一个符合 Angular 规范的 Commit Message：

fix($compile): couple of unit tests for IE9
# Please enter the Commit Message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# ...Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.Closes #392
Breaks foo.bar api, foo.baz should be used instead

1. Header

Header 部分只有一行，包括三个字段：type（必选）、scope（可选）和 subject（必选）。

1.1 type

type 用来说明 commit 的类型。主要可以归为 Development 和 Production 共两类：

Development：这类修改一般是项目管理类的变更，不会影响最终用户和生产环境的代码，比如 CI 流程、构建方式等的修改。遇到这类修改，通常也意味着可以免测发布。
Production：这类修改会影响最终的用户和生产环境的代码。所以对于这种改动，我们一定要慎重，并在提交前做好充分的测试。

这里列出了 Angular 规范中的常见 type 和它们所属的类别，你在提交 Commit Message 的时候，一定要注意区分它的类别。

有这么多 type，我们该如何确定一个 commit 所属的 type 呢？这里我们可以通过下面这张图来确定。

如果我们变更了应用代码，那这次修改属于代码类。在代码类中，有 4 种具有明确变更意图的类型：feat、fix、perf 和 style；如果我们的代码变更不属于这 4 类，那就全都归为 refactor 类，也就是优化代码。

如果我们变更了非应用代码，例如更改了文档，那它属于非代码类。在非代码类中，有 3 种具有明确变更意图的类型：test、ci、docs；如果我们的非代码变更不属于这 3 类，那就全部归入到 chore 类。

1.2 scope

scope 是用来说明 commit 的影响范围的，它必须是名词。显然，不同项目会有不同的 scope。在项目初期，我们可以设置一些粒度比较大的 scope，比如可以按组件名或者功能来设置 scope；后续，如果项目有变动或者有新功能，我们可以再用追加的方式添加新的 scope。

1.3 subject

subject 是 commit 的简短描述，必须以动词开头、使用现在时。比如，我们可以用 change，却不能用 changed 或 changes，而且这个动词的第一个字母必须是小写。通过这个动词，我们可以明确地知道 commit 所执行的操作。此外我们还要注意，subject 的结尾不能加英文句号。

2. Body

Header 对 commit 做了高度概括，可以方便我们查看 Commit Message。那我们如何知道具体做了哪些变更呢？

答案就是，可以通过 Body 部分，它是对本次 commit 的更详细描述，是可选的。Body 部分可以分成多行，而且格式也比较自由。不过，和 Header 里的一样，它也要以动词开头，使用现在时。此外，它还必须要包括修改的动机，以及和跟上一版本相比的改动点。

3. Footer

Footer 部分不是必选的，可以根据需要来选择，主要用来说明本次 commit 导致的后果。在实际应用中，Footer 通常用来说明不兼容的改动和关闭的 Issue 列表，格式如下：

BREAKING CHANGE: <breaking change summary>
// 空行
<breaking change description + migration instructions>
// 空行
// 空行
Fixes #<issue number>

接下来，我给你详细说明下这两种情况：

不兼容的改动：如果当前代码跟上一个版本不兼容，需要在 Footer 部分，以 BREAKING CHANG: 开头，后面跟上不兼容改动的摘要。Footer 的其他部分需要说明变动的描述、变动的理由和迁移方法


BREAKING CHANGE: isolate scope bindings definition has changed andthe inject option for the directive controller injection was removed.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 列表：关闭的 Bug 需要在 Footer 部分新建一行，并以 Closes 开头列出，例如：Closes #123。如果关闭了多个 Issue，可以这样列出：Closes #123, #432, #886。例如:

Change pause version value to a constant for imageCloses #1137

4. Revert Commit

除了 Header、Body 和 Footer 这 3 个部分，Commit Message 还有一种特殊情况：如果当前 commit 还原了先前的 commit，则应以 revert: 开头，后跟还原的 commit 的 Header。而且，在 Body 中必须写成 This reverts commit ，其中 hash 是要还原的 commit 的 SHA 标识。例如：

revert: feat(iam-apiserver): add 'Host' optionThis reverts commit 079360c7cfc830ea8a6e13f4c8b8114febc9b48a.

为了更好地遵循 Angular 规范，建议你在提交代码时养成不用 git commit -m，即不用 -m 选项的习惯，而是直接用 git commit 或者 git commit -a 进入交互界面编辑 Commit Message。这样可以更好地格式化 Commit Message。

参考：
https://time.geekbang.org/column/article/380989

规范的 Commit Message相关推荐

Git Commit Message校验踩坑指南
背景在团队多人开发中,规范的commit message可以快速定位代码提交历史,回溯问题根源,方便组内多人协作,提高团队效率. 本篇文章主要包含以下两方面内容: commitizen/cz-cli ...
根据 commit message 自动生成 changelog
前面和大家介绍了commitlint + Husky 规范 git commit 日志,提及了规范的 commit message 有助于团队其它人员 review,还可以有效的输出 CHANGELO ...
Angular标准 commit message 提交信息、commit 验证、standard-version 自动版本更替和 changelog 输出
辅助提交工具因为要使用 commitizen 工具来辅助提交信息填写 npm install commitizen -g 进而需要先安装 node 环境使用在项目目录下 # 需要先 npm in ...
Git commit message和工作流规范
总体方案 Git commit日志基本规范 <type>(<scope>): <subject><BLANK LINE><body>< ...
Git学习总结（23）——Git commit message和版本管理规范总结
一.Git commit message基本规范对格式的说明如下: type代表某次提交的类型,比如是修复一个bug还是增加一个新的feature.所有的type类型如下: feat: 新增feat ...
Commit Message 规范
目前 Commit Message 规范比较常见的有 Angular 团队的规范,并由此衍生出了 Conventional Commits Specification,可以参照此 Specificat ...
git commit message——git提交日志规范备忘
使用git提交时,最好能注意保持规范,可能某些公司对这方面没有要求,但是提交日志不规范的话,不方便查阅和管理. 在此记录下commit的类别,备忘,更详细的介绍,可以查看文末链接. commit me ...
Git 提交的正确姿势：Commit message 编写指南
Git 每次提交代码,都要写 Commit message(提交说明),否则就不允许提交. $ git commit -m "hello world" 上面代码的-m参数,就是用来 ...
commitizen和cz-customizable配置git commit message 1
起因团队对提交的commit message格式有约定俗称的要求,但是没有一个统一的规范,导致大家提交的commit message或多或少不太一样.因此,需要一个工具来帮助大家统一commit m ...

规范的 Commit Message