规范 commit 与 changelog 生成 #19
Description
一个良好的提交习惯，绝对会为以后的代码维护带来不小的收益。
举个例子，某天你自己写的一个功能出问题了，找到代码被修改的地方，发现是一个同事修改了一行代码，这个时候你一脸懵逼，因为他既没有写注释，commit 记录也只是随便写了一句，完全搞不明白为什么要那样修改。你想改回去，又怕影响其它的地方，不改回去，就只能想办法改自己原来的逻辑。
一个好的提交信息完全可以避免这种情况，changelog 信息也同样如此，能很好的帮助回归一段时间内都做了些什么，了解项目的整个进度，并且有助于 code review。
Git Commit 规范
规范采用 Angular Git Commit Guidelines
Commit Message 格式
每条 Commit message 都包括三个部分：header, body 和 footer。
header 比较特殊，也包含三个部分：type, scope 和 subject
具体格式如下：
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
每行不能超过 50 个中文长度。
Revert
If the commit reverts a previous commit, it should begin with revert:, followed by the header
of the reverted commit.
In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit
being reverted.
A commit with this format is automatically created by the [git revert][git-revert] command.
Type（必须）
本次 commit 的类型，必须是下面几项之一:
- feat: 一个新功能
- fix: 一个 bug 修复
- docs: 仅仅修改了文档，比如 README, CHANGELOG, CONTRIBUTE 等
- style: 不影响代码逻辑的修改，比如空格、格式缩进、删除分号等
- refactor: 代码重构
- perf: 提升性能的改动
- test: 增加或修改测试
- chore: 改变构建流程、或者增加辅助工具、依赖库等
Scope（可选）
scope 用于指定 commit 影响的范围
You can use * when the change affects more than a single scope.
Subject（必须）
subject 是对此次修改的简短描述:
* 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
* 首字母小写
* 结尾不加句号
Body（可选）
对此次修改目的与动机的详细文字说明：
* 具体增加了什么功能？
* 为什么要这样修改？
* 如何解决这个问题的？
* 是否存在副作用或其它风险？
Footer（可选）
Breaking Changes 即破坏性变动，比如不兼容修改。
也可以用来关闭 issues，Closes #123, #245, #992。
在普通业务项目中基本用不到这个。
commit 工具 —— commitizen
首先安装 Commitizen cli:
npm install commitizen -g
然后，在你的项目里运行下面的命令（每个新的项目都需要）：
commitizen init cz-conventional-changelog --save-dev --save-exact
之后，就可以用 git cz 代替 git commit 进行提交了：
具体文档查看 cz-cli。
commit 模板
对于一般的项目开发而言，每次提交都使用 commitizen cli 还是会比较费时间，而且按快了容易选错，所以在日常开发中更建议使用 commit 模板。
方法一：
右键打开 TortoiseGit 设置界面
添加 commit 模板
注：路径应为两个反斜杠或斜杠进行分割，模板需要自己创建一个 txt 文件并编写。
使用 TortoiseGit 提交时的样子：
方法二：
使用原生 git
git config — —global commit.template [模板文件名]
注：这个方法没用过，如果遇到问题，请自行百度
自动生成 Change log
只要 commit message 符合 Angular 那套规范，我们就可以用 standard-version 这样的工具来自动生成 CHANGELOG 文件。
首先安装到开发环境
npm install --save standard-version
然后配置 package.json
"scripts": {
"release-f": "standard-version -f",
"release-major": "standard-version -r major",
"release-minor": "standard-version -r minor",
"release-patch": "standard-version -r patch"
}CLI 命令选项：
--release-as, -r Specify the release type manually (like npm version <major|minor|patch>)
[string]
--prerelease, -p make a pre-release with optional option value to specify a tag id [string]
--infile, -i Read the CHANGELOG from this file [default: "CHANGELOG.md"]
--message, -m Commit message, replaces %s with new version
[string] [default: "chore(release): %s"]
--first-release, -f Is this the first release? [boolean] [default: false]
--sign, -s Should the git commit and tag be signed? [boolean] [default: false]
--no-verify, -n Bypass pre-commit or commit-msg git hooks during the commit phase
[boolean] [default: false]
--commit-all, -a Commit all staged changes, not just files affected by standard-version
[boolean] [default: false]
--silent Don't print logs and errors [boolean] [default: false]
--tag-prefix, -t Set a custom prefix for the git tag to be created [string] [default: "v"]
--scripts Provide scripts to execute for lifecycle events (prebump, precommit,
etc.,) [default: {}]
--skip Map of steps in the release process that should be skipped [default: {}]
--dry-run See the commands that running standard-version would run
[boolean] [default: false]
--version, -v Show version number [boolean]
--help, -h Show help [boolean]
major：通常代表一个大的版本更新；minor：代表功能添加；patch：代表 bug 修复
major：1.0.0 -> 2.0.0, minor: 1.0.0 -> 1.1.0, patch : 1.0.0 -> 1.0.1