当前位置:   article > 正文

使用 commitizen 和 standard-version 自动化 JavaScript 项目版本控制_standard-version --release-as major

standard-version --release-as major

本文为译文,原为为:Christian Ing SunardiAutomate 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 会更新 minorbug fix 会更新 patchBREAKING CHANGES 会更新 major)。commitizen 可以帮助我们提交符合 Conventional Commit Specifications 的 commit message。

  1. 在你的 JavaScript 项目中安装 commitizen:
npm install -D commitizen
  1. 设置 changelog adapter:
commitizen init cz-conventional-changelog --save-dev --save-exact
  1. 在 package.json,中增加如下脚本:
  1. "scripts": {
  2. "commit" : "git-cz"
  3. }

首先我们 git add . 文件,然后 npm run commit,此时 commitizen 会通过 CLI 对我们进行询问:

选择提交类型后,会需要我们填写详细信息:

detail.png

至此,我们的修改已经被成功提交,可以开始配置 standard-version 了。

安装 standard-version

当我们使用 commitizen 进行标准化提交之后,我们就可以使用 standard-version 进行版本管理自动化了,包括更新 CHANGELOG.md,以及使用 git tag

  1. 安装 standard-version
npm install -D standard-version
  1. 在 package.json 中编写响应的脚本:
  1. "scripts": {
  2. "commit" : "git-cz",
  3. "release": "standard-version"
  4. }

为了合理的使用 standard-version,我们首先需要 git add . 文件,然后执行 npm run commit,最后执行 npm run release

CHANGELOG.md 配置

默认情况下,standard-version 只会在 CHANGELOG.md 中记录 feat 和 fix 类型的提交。如果想记录其他类型的提交,需要如下步骤:

  • 在项目的根目录下创建一个名为 .versionrc 的文件,并粘贴复制一下内容:
  1. // .versionrc
  2. {
  3. "types": [
  4. {"type": "chore", "section":"Others", "hidden": false},
  5. {"type": "revert", "section":"Reverts", "hidden": false},
  6. {"type": "feat", "section": "Features", "hidden": false},
  7. {"type": "fix", "section": "Bug Fixes", "hidden": false},
  8. {"type": "improvement", "section": "Feature Improvements", "hidden": false},
  9. {"type": "docs", "section":"Docs", "hidden": false},
  10. {"type": "style", "section":"Styling", "hidden": false},
  11. {"type": "refactor", "section":"Code Refactoring", "hidden": false},
  12. {"type": "perf", "section":"Performance Improvements", "hidden": false},
  13. {"type": "test", "section":"Tests", "hidden": false},
  14. {"type": "build", "section":"Build System", "hidden": false},
  15. {"type": "ci", "section":"CI", "hidden":false}
  16. ]
  17. }
  • "type" commit 类型
  • "section" 不同的 commit 类型所在 CHANGELOG.md 中的区域
  • "hidden" 是否在 CHANGELOG.md 中显示

开发工作流

截至目前,所有的配置已经设置完毕。让我们用一个真实的开发工作流来梳理一下 *commitizen * 与 standard-version 的使用。

workflow.png

  1. [feature-branch] stage 更改的文件:
git add .
  1. [feature-branch] 用 git-cz 来提交文件:
npm run commit
  • 选择提交类型(feat, refactor, fix, 等等)
  • 提供简短描述
  • (可选)提供长描述
  • 确定本次提交是否为 BREAKING CHANGES
  • (可选)提供 JIRA issue
  1. [feature-branch] 推送远端
git push origin <feature-branch>
  1. [Bitbucket] 向 master 分支提交 Pull Request
  2. [master] 成功合并后:
    • 执行命令 npm run release (自动更新版本号,自动更新 CHANGELOG.md, 自动创建 git tag)
    • 将更改和 git tags 推送至远端:
    git push --follow-tags origin master
    
  3. Relax and enjoy
    声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/凡人多烦事01/article/detail/673996
推荐阅读
相关标签