本文为译文，原为为：Christian Ing Sunardi: Automate JavaScript project versioning with commitizen and standard-version
其实手动更新版本号，changelog, 创建 git tags 还是比较麻烦的。有没有更好的方法？别怕，使用 standard-version ，只需要一行命令，就会帮你搞定一切！为实现自动化版本控制，有一些基础配置需要做。
安装 commitizen
在使用 standard-version 之前，需要遵循 Conventional Commit Specifications 来进行标准化的 commit message 编写。这是因为 standard-version 是基于 commit 类型来更新版本号的（feature 会更新 minor, bug fix 会更新 patch, BREAKING CHANGES 会更新 major）。commitizen 可以帮助我们提交符合 Conventional Commit Specifications 的 commit message。
- 在你的 JavaScript 项目中安装 commitizen：
npm install -D commitizen
- 设置 changelog adapter：
commitizen init cz-conventional-changelog --save-dev --save-exact
- 在 package.json，中增加如下脚本：
"scripts": {
"commit" : "git-cz"
}
首先我们 git add . 文件，然后 npm run commit，此时 commitizen 会通过 CLI 对我们进行询问：
选择提交类型后，会需要我们填写详细信息：
至此，我们的修改已经被成功提交，可以开始配置 standard-version 了。
安装 standard-version
当我们使用 commitizen 进行标准化提交之后，我们就可以使用 standard-version 进行版本管理自动化了，包括更新 CHANGELOG.md，以及使用 git tag。
- 安装 standard-version：
npm install -D standard-version
- 在 package.json 中编写响应的脚本：
"scripts": {
"commit" : "git-cz",
"release": "standard-version"
}
为了合理的使用 standard-version，我们首先需要 git add . 文件，然后执行 npm run commit，最后执行 npm run release。
CHANGELOG.md 配置
默认情况下，standard-version 只会在 CHANGELOG.md 中记录 feat 和 fix 类型的提交。如果想记录其他类型的提交，需要如下步骤：
- 在项目的根目录下创建一个名为
.versionrc的文件，并粘贴复制一下内容：
// .versionrc
{
"types": [
{"type": "chore", "section":"Others", "hidden": false},
{"type": "revert", "section":"Reverts", "hidden": false},
{"type": "feat", "section": "Features", "hidden": false},
{"type": "fix", "section": "Bug Fixes", "hidden": false},
{"type": "improvement", "section": "Feature Improvements", "hidden": false},
{"type": "docs", "section":"Docs", "hidden": false},
{"type": "style", "section":"Styling", "hidden": false},
{"type": "refactor", "section":"Code Refactoring", "hidden": false},
{"type": "perf", "section":"Performance Improvements", "hidden": false},
{"type": "test", "section":"Tests", "hidden": false},
{"type": "build", "section":"Build System", "hidden": false},
{"type": "ci", "section":"CI", "hidden":false}
]
}
-
"type"commit 类型 -
"section"不同的 commit 类型所在 CHANGELOG.md 中的区域 -
"hidden"是否在 CHANGELOG.md 中显示
开发工作流
截至目前，所有的配置已经设置完毕。让我们用一个真实的开发工作流来梳理一下 *commitizen * 与 standard-version 的使用。
- [feature-branch] stage 更改的文件：
git add .
- [feature-branch] 用
git-cz来提交文件：
npm run commit
- 选择提交类型（feat, refactor, fix, 等等）
- 提供简短描述
- （可选）提供长描述
- 确定本次提交是否为 BREAKING CHANGES
- （可选）提供 JIRA issue
- [feature-branch] 推送远端
git push origin <feature-branch>
- [Bitbucket] 向
master分支提交 Pull Request - [master] 成功合并后：
- 执行命令
npm run release(自动更新版本号，自动更新 CHANGELOG.md, 自动创建git tag) - 将更改和
git tags推送至远端:
git push --follow-tags origin master - 执行命令
- Relax and enjoy 🍕
总结
使用以上流程进行版本发布是一种非常好的最佳实践。因为我们可以非常轻松的追溯虽有的更新。并且一切都是自动化的。
常见坑🤔
- 如果当前版本没有主版本号，则
BREAKING CHANGEScommit 不会更新主版本号！！！比如当前版本号为0.1.2，我们运行npm run release则只会更新minor和patch版本号（参考：https://github.com/conventional-changelog/standard-version/issues/429
）。 - 为了正确的更新主版本号，我们需要显式的进行：
standard-version -- --release-as major
注意： standard-version 后的 双横线 -- 是必须的。在 --release-as 和 major 之间是有空格的。
- 此后，我们再次发布包含
BREAKING CHANGES类型的提交，则能够自动更新主版本号👍🎉。 - 如果有多次提交，则版本号更新是有优先级的：
- major 或者
BREAKING CHANGES高于minor和patch -
minor高于patch
- major 或者
