每次提交代码时，由于每个人的习惯不同，导致commit信息不明确，
所以，为了能使得日后复（zhao）盘（guo）的时候更加的方便，团队之间遵守同一套 commit message 规范还是很有必要的。(转)
commit message 的作用
- 提供更多的历史信息，方便快速浏览。
- 可以过滤某些commit（比如文档改动），便于快速查找信息。
- 可以直接从commit生成Change log。
定制 commit message规范
IDEA安装插件 Git Commit Template
1、搜索commit message template并安装，安装完重启
2、提交代码
- Header
Header的部分只有一行,包括三个字段: type(必需), scope(可选), subject(必需)
对应到idea插件上图的配置分别为 Header部分的:
type(必需) Type of change commit类别
scope(可选) Scope of this change commint影响的范围
subject(必需) Short description 简短的描述
(1)type用于说明 commit 的类别，只允许使用下面7个标识
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动,空格,格式化,等等）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
perf: 性能 (提高代码性能的改变)
test：增加测试或者修改测试
build: 影响构建系统或外部依赖项的更改(maven,gradle,npm 等等)
ci: 对CI配置文件和脚本的更改
chore：对非 src 和 test 目录的修改
revert: Revert a commit
(2) scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
(3) subject
subject是 commit 目的的简短描述，不超过50个字符。
以动词开头，使用第一人称现在时，比如change，而不是changed或changes
第一个字母小写
结尾不加句号（.）
- Body
Body 部分是对本次 commit 的详细描述，可以分成多行。
有两个注意点。
（1）使用第一人称现在时，比如使用change而不是changed或changes。
（2）应该说明代码变动的动机，以及与以前行为的对比。
- Footer
Footer 部分只用于两种情况。
（1）不兼容变动
如果当前代码与上一个版本不兼容，则 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.
（2）关闭 Issue
如果当前 commit 针对某个issue，那么可以在 Footer 部分关闭这个 issue 。
Closes #234
也可以一次关闭多个 issue 。
Closes #123, #245, #992
示例
commit规范已经做完了，接下来就是要把所有的commit信息记录在changelog里。
1、commitizen安装
cnpm install -g commitizen
会自动在项目根路径生成package.json
2、安装适配器
cnpm install cz-conventional-changelog --save-dev
commitizen 工具会自动在package.json中添加配置相应的配置，具体如下："config": {"commitizen": {"path": "cz-conventional-changelog"}}
3、安装conventional-changelog-cli
cnpm install -g conventional-changelog-cli
基本使用
conventional-changelog -p angular -i CHANGELOG.md -s
以上命令中参数-p angular用来指定使用的 commit message 标准
参数-i CHANGELOG.md表示从 CHANGELOG.md 读取 changelog, -s 表示读写 changelog 为同一文件。需要注意的是，上面这条命令产生的 changelog 是基于上次 tag 版本之后的变更（Feature、Fix、Breaking Changes等等）所产生的，所以如果你想生成之前所有 commit 信息产生的 changelog 则需要使用这条命令：$ conventional-changelog -p angular -i CHANGELOG.md -s -r 0其中 -r 表示生成 changelog 所需要使用的 release 版本数量，默认为1，全部则是0。
那么 tag 版本是怎么指定的呢，请看package.json
{
"devDependencies": {
"commitizen": "^4.0.3",
"cz-conventional-changelog": "^3.0.2"
},
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
}
},
"version": "1.0.2",
"scripts": {
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md"
}
}
version即是当前版本号，需要手动指定
那么如何生成changelog呢
changelog是记录版本之间的变化
通常情况线下，我们会在 master 分支进行如下的版本发布操作
- git pull origin master
- 根据 pacakage.json 中的 version 更新版本号，更新 changelog
- git add -A, 然后 git commit
- git tag 打版本操作
- push 版本 tag 和 master 分支到仓库
tag打完之后会有新的版本号，将此版本号更新到pacakage.json 中的 version字段，执行
npm run changelog
之后changelog已经有更新了，更新会自动分类
