共计 4098 个字符，预计需要花费 11 分钟才能阅读完成。
因为入职至今，公司也没有太规定一个代码提交标准，所以始终以来，我代码提交的 commit message 都是简略的一句话阐明了本次代码改变内容，有时候会更加精简。
但工夫长了之后，当我须要回头找一下某次提交记录的时候，就会发现不太好找，首先没有一个具体的分类，比方是增加性能、还是修复 bug、还是更新文档等等；其次就是有一些 message 写得不是很清晰，不太能一眼明了那次改变是什么内容。
起初决定，须要从新学一学对于 commit message 的写法标准。
Commit Message 的益处
- 每一条提交记录的
message可能提供更多的无效信息，不便咱们疾速浏览； - 能够应用
git log --grep <keyword>过滤掉某些commit，便于疾速查找信息； - 能够间接从
commit生成Change log。
Commit Message 格局
目前 Commit Message 标准应用较多的是 Angular 团队的标准，继而衍生了 Conventional Commits sepcification。
Commit Message包含三个局部：Header、Body和Footer。格局如下：
<type>(<scope>): <subject>
< 空一行 >
<body>
< 空一行 >
<footer>其中，Header是必填的，Body和 Footer 能够省略不写。
Header
Header蕴含三个局部：type、scope和 subject。其中scope 是可选项。
<type>(<scope>): <subject>
# example
feat($route): add support for the `reloadOnUrl` configuration optiontype
type是用于阐明 commit 的类别，具体的标识如下：
feat：一个新的性能（feature）；fix：修复bug;docs：批改文档，比方README.md、CHANGELOG.md等；style: 批改代码的格局，不影响代码运行的变动，比方空格、格式化代码、补齐句末分号等等；refactor: 代码的重构，没有新性能的增加以及 bug 修复的代码改变；perf：优化代码以进步性能；test：减少测试或优化改善现有的测试；build：批改影响我的项目构建文件或内部依赖项，比方npm、gulp、webpack、broccoli等；ci：批改 CI 配置文件和脚本；chore：其余非 src 门路文件和测试文件的批改，比方.gitignore、.editorconfig等；revert：代码回退；
scope
scope是用于阐明 commit 的影响范畴，比方数据层、管制层、视图层等等，视我的项目不同而不同。
如果你的批改影响了不止一个 scope，就能够应用* 代替。
subject
subject是 commit 的目标简略形容，不超过 50 个字符，结尾不须要句号。
Body
Body局部是对本次 commit 的详细描述，能够分为多行。
Body局部应该阐明代码变动的动机，以及与以前行为的比照。
More detailed explanatory text, if necessary. Wrap it to about 72 characters or so.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Use a hanging indentFooter
Footer局部次要用于两种状况：不兼容变动和解决Issue。
不兼容变动
如果以后代码与上一个版本不兼容，则 Footer 局部以 BREAKING CHANGE: 结尾，前面就是对变动的形容、以及变动理由和迁徙办法。
BREAKING CHANGE: Previously, $compileProvider.preAssignBindingsEnabled was set to true by default. This means bindings were pre-assigned in component constructors. In Angular 1.5+ the place to put the initialization logic relying on bindings being present is the controller $onInit method.
To migrate follow the example below:
Before:
```js
angular.module('myApp', [])
.component('myComponent', {bindings: {value: '<'},
controller: function() {this.doubleValue = this.value * 2;}
});
```
After:
```js
angular.module('myApp', [])
.component('myComponent', {bindings: {value: '<'},
controller: function() {this.$onInit = function() {this.doubleValue = this.value * 2;};
}
});
this.doubleValue = this.value * 2;
};
}
});
```
Don't do this if you're writing a library, though, as you shouldn't change global configuration then.解决 Issue
如果以后 commit 是针对解决某个 issue，那么能够在Footer 局部标注解决的issue。
Fixes #234如果想敞开这个 issue 的话：
Closes #234相干插件
Commitizen – 疾速编写 Commit Message
https://github.com/commitizen…
咱们能够利用第三方插件 Commitizen 来疾速编写咱们的Commit Message。
首先全局装置一下Commitizen。
npm i -g commitizen而后在咱们的我的项目门路下，运行下列命令，使其反对 Angular 的Commit Message格局。
commitizen init cz-conventional-changelog --save --save-exact装置实现后，咱们每次提交代码，就不再应用 git commit -m 命令了，而是应用 git cz 来执行操作。
git cz先抉择一下Commit Type，而后回车确定。
cz-cli@4.2.4, cz-conventional-changelog@3.3.0
? Select the type of change that you're committing: (Use arrow keys)
❯ feat: A new feature
fix: A bug fix
docs: Documentation only changes
style: Changes that do not affect the meaning of the code (white-space, for
matting, missing semi-colons, etc)
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
(Move up and down to reveal more choices)而后输出 scope 的信息。
What is the scope of this change (e.g. component or file name): (press enter to skip)而后输出 subject 信息。
Write a short, imperative tense description of the change (max 85 chars):紧接着配置 Boby 的信息。
Provide a longer description of the change: (press enter to skip):
? Are there any breaking changes? Yes
? A BREAKING CHANGE commit requires a body. Please enter a longer description of
the commit itself:最初配置 Footer 信息。
Describe the breaking changes:
? Does this change affect any open issues? Yes
? Add issue references (e.g. "fix #123", "re #123".):Commitlint — 校验你的 Commit Message
https://github.com/marionebl/…
Commitlint能够帮忙咱们查看Commit Messages, 如果咱们提交的不合乎指向的标准的话，就会间接回绝提交。
因而，咱们也须要向它提供一份校验的配置，这里举荐 @commitlint/config-conventional (合乎 Angular 团队标准)。
装置：
npm i -D @commitlint/config-conventional @commitlint/cli同时须要在我的项目目录下创立配置文件.commitlintrc.js，写入：
module.exports = {
extends: ["@commitlint/config-conventional"],
rules: {}};更多相干配置能够去查阅一下官网文档。
Standard Version — 主动生成 CHANGELOG
https://github.com/convention…
当咱们的 Commit Message 合乎 Angular 团队标准的状况下，咱们就能够借助 standard-version 这样的工具，主动生成 CHANGELOG，甚至是语义化的版本号(Semantic Version)。
装置：
npm i -S standard-versionpackage.json配置：
"scirpt": {"release": "standard-version"}
