使用idea 生成changelog文件自动更新说明

每次提交代码时，由于每个人的习惯不同，导致commit信息不明确，
所以，为了能使得日后复（zhao）盘（guo）的时候更加的方便，团队之间遵守同一套 commit message 规范还是很有必要的。(转)

commit message 的作用

提供更多的历史信息，方便快速浏览。
可以过滤某些commit（比如文档改动），便于快速查找信息。
可以直接从commit生成Change log。

定制 commit message规范

IDEA安装插件 Git Commit Template
1、搜索commit message template并安装，安装完重启

780_1.png

2、提交代码

Image [2].png

781_1.png

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

示例

782_1.png

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已经有更新了，更新会自动分类

image.png