git commit 、CHANGELOG 和版本发布的标准自动化

一直以来，由于团队项目迭代节奏很快，每次发布的更新日志和版本更新都是经过人肉来完成的。有时候实在忙的团团转，对于手动的写这些更新信息就显得力不从心了。对于团队新来的小伙伴，有时候遇到些紧急状况，就更显的乱糟糟，仍是得麻烦团队资深的同窗。显然这些工做，用自动化工具再适合不过了。 

本文是一篇项目自动化方面的使用教程，社区里面针对四类问题的解决方案不少，今天这里主要介绍的是 onventional-changelog 方案相关的内容。 若是你正在思考或者试图解决这方面的问题的话，不妨了解一下。

conventional-changelog

conventional-changelog 是一款能够根据项目的commit 和 metadata信息自动生成 changelogs 和 release notes的系列工具，而且在辅助 standard-version 工具的状况下，能够自动帮你完成生成version、打tag, 生成CHANGELOG等系列过程。

conventional-changelog 生态主要模块

• conventional-changelog-cli - conventional-changelog 核心命令行工具
• standard-changelog - 针对 angular commit 格式的命令行工具
• conventional-github-releaser - 利用 git metadata 针对 Github 的发布工具
• conventional-commits-detector - commit message 规范引用检测
• commitizen - 针对开发者简单的 commit 规范
• commitlint - commit Lint 工具

以上是 onventional-changelog 生态重要的几个主要模块，实际工做中这几个工具经常是配套使用的，固然也须要根据本身的状况而定。篇幅有限，今天咱们就主要介绍 commitizen、conventional-changelog-cli 、standard-version 这三工具了。

commitizen

commitizen 是一款标准化 git commit 信息的工具。在没有规范的状况下，开发人员的 commit 信息是经常是随意的，这就致使 commit 信息显的很无用。但是当你在作git log、code review、编写changelog等状况时，良好的 commit 规范就显的尤其重要。

commitizen 安装

$ npm install -g commitizen
# 或者本地安装 $ npm install --save-dev commitizen 

安装适配器（Adapter)

由于不一样的项目自己的构建方式的不一样，commitizen 支持不一样适配器的扩展，从而去知足不一样的构建需求的。本文主要使用cz-conventional-changelog的构建标准，固然你也能够根据具体的状况选择其余的适配器，更多请看。

$ npm install -g cz-conventional-changelog

全局安装完成后，咱们须要在项目根目录下添加 .czrc 配置文件，文件内容以下：

// path 用来指定适配器 { "path": "cz-conventional-changelog" } 

本地安装

$ npm install cz-conventional-changelog --save-dev
# 或者使用 commitizen 工具 $ commitizen init cz-conventional-changelog --save-dev --save-exact 

commitizen 工具会自动在package.json中添加配置相应的配置，具体以下：

"config": { "commitizen": { "path": "cz-conventional-changelog" } } 

安装并添加完后，咱们即可以使用 git cz 命令替换 git commit 来使用了。咱们修改一个文件并 git add 后，经过 git cz 试一下：

能够看到，git cz 给出了 commit 的几种类型选项，以下：

• feat 新功能
• fix Bug 修复
• docs 文档更新
• style 代码的格式，标点符号的更新
• refactor 代码重构
• perf 性能优化
• test 测试更新
• build 构建系统或者包依赖更新
• ci CI 配置，脚本文件等更新
• chore 非 src 或者 测试文件的更新
• revert commit 回退

使用的时候，咱们应该根据项目具体变动状况选择。若是想修改已经打好的 commit 信息，咱们能够经过 git reset命令来修复。

须要注意的是，仅仅是添加 commit 工具是不够的，为了保证 commit 格式的一致性，这里强烈建议你记得整合 commitlint 工具, 配合 git commit-msg hook 来使用，在这里就不相信介绍了，具体能够查看官方文档。

conventional-changelog-cli

conventional-changelog-cli 默认推荐的 commit 标准是来自angular项目,除了 angular 标准之外，目前集成了包括 atom, codemirror, ember, eslint, express, jquery 等项目的标准，具体能够根据本身口味来选用。

安装

# Help conventional-changelog --help $ npm install -g conventional-changelog-cli 

基本使用

$ conventional-changelog -p angular -i CHANGELOG.md -s

以上命令中参数-p angular用来指定使用的 commit message 标准，假如想使用atom的标准，则是：

$ conventional-changelog -p atom -i CHANGELOG.md -s

参数-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。

自定义参数

生成的 changlog 中有些经常使用内容能够经过自定义参数来根据需求更改，例如版本号、commit 地址等等。 changelog 中生成的版本号便是从 package.json 中获取 version 字段来的。commit 链接的仓库地址咱们须要修改 package.json 中的repository地址，changelog 中 issuse 默认的链接地址也是根据 repository 来生成的。若是你使用了第三方的协做系统（例如 bitbucket）， 那么你可使用这个标准conventional-changelog-angular-bitbucket。或者像咱们使用 redmine 来管理 isssue ，那么在生成 changelog 后可使用 replace 工具来处理文本中的原有地址：

$ replace 'https://github.com/myproject/issues/' 'https://redmine.example.com' CHANGELOG.md 

最后看看大体生成的效果：

conventional-changelog 更多的选项配置能够看这里。

standard-version

standard-version 是一款遵循语义化版本（ semver）和 commit message 标准规范 的版本和 changlog 自动化工具。一般状况线下，咱们会在 master 分支进行以下的版本发布操做：

1. git pull origin master
2. 根据 pacakage.json 中的 version 更新版本号，更新 changelog 3. git add -A, 而后 git commit 4. git tag 打版本操做 5. push 版本 tag 和 master 分支到仓库 

其中2，3，4则是 standard-version 工具会自动完成的工做，配合本地的 shell 脚本，则能够自动完成一系列版本发布的工做了。

安装 & 使用

在这里我仍然推荐的全局安装：

$ npm install -g standard-version
# 或者 $ npm install --save-dev standard-version 

执行：

# Help standard-version --help $ standard-version 

执行 standard-version 命令，咱们会在控制台看到整个执行流程的 log 信息，在这里几个经常使用的参数须要注意下:

--release-as, -r 指定版本号

默认状况下，工具会自动根据 主版本（major）,次版本（ minor） or 修订版（patch） 规则生成版本号，例如若是你package.json 中的version 为 1.0.0, 那么执行后版本号则是：1.0.1。自定义能够经过：

$ standard-version -r minor
# output 1.1.0 $ standard-version -r 2.0.0 # output 2.0.0 $ standard-version -r 2.0.0-test # output 2.0.0-test 

须要注意的是，这里的版本名称不是随便的字符，而是须要遵循语义化版本（ semver） 规范的

--prerelease, -p 预发版本命名

用来生成预发版本, 若是当期的版本号是 2.0.0，例如

$ standard-version --prerelease alpha
# output 2.0.0-alpha.0 

--tag-prefix, -t 版本 tag 前缀

用来给生成 tag 标签添加前缀，例如若是前版本号为 2.0.0，则：

$ standard-version --tag-prefix "stable-" # output tag: stable-v2.0.0 

以上这几个参数可能咱们用的比较多，还有其余选项能够经过 standard-version --help查看。

集成 npm

最后记得把命令集成到 npm package.json的 scripts 中, 并配合 shell 脚本使用, 以下：

"scripts": { "release": "./scripts/release.sh", "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md && npm run changeissueurl", "changeissueurl": "replace 'https://github.com/myproject/issues/' 'https://redmine.example.com/' CHANGELOG.md" }, // 配置好后使用 npm run 执行发布 $ npm run release 

添加 release.sh 脚本：

#!/bin/bash # Release branch master="master" prefix="DTinsight_v" git pull origin $master echo "Current pull origin $master." # Auto generate version number and tag standard-version -r $release --tag-prefix $prefix git push --follow-tags origin $master echo "Git push origin $master" echo "Release finished." 

上面的脚本只是作了简单的分支 pull, 执行 standard-version 和最后的版本 push 工做，若是要作一些定制化的执行参数，则须要作定制修改了。

最后

项目的工程化是一件颇有意思的事情，经过自动化的工具，能够有效提高项目可维护性和质量，而且避免不少不肯定因素。若是你工做中发现了这些问题，而不想继续经过人肉的方法解决这些问题的话，那就赶忙试试~

原文地址：http://imziv.com/blog/article/index.htm