规范化 Git 版本提交信息和版本发布
本文讲解了如何利用工具 commitizen/cz-cli + commitizen/cz-conventional-changelog + conventional-changelog/standard-version,规范提交信息和版本发布。
前言
协作开发下不同开发人员的 commit 书写习惯不同,查看 commit 记录时感觉就比较乱且不尽详细。我自己也是,没有一套合适的 commit 规范约束,每次都只是大概写个主要概述就提交,当需要返回查看时就看不出太多信息了。同时 CHANGELOG 也是记录的不尽详细,之前的手动书写不能让我们查看项目的每个发行版之间发生的变化。也所以上网查找了下解决方案,感觉甚好,有必要总结一下。
约定式提交规范
约定式提交规范是基于Angular提交准则形成,提交说明的结构如下:
<类型>[可选的作用域]: <描述>
[可选的正文]
[可选的脚注]
其中,<类型>
是为了向类库使用者表明其意图,其可选值为:
- feat: 表示新增了一个功能
- fix: 表示修复了一个 bug
- docs: 表示只修改了文档
- style: 表示修改格式、书写错误、空格等不影响代码逻辑的操作
- refactor: 表示修改的代码不是新增功能也不是修改 bug,比如代码重构
- perf: 表示修改了提升性能的代码
- test: 表示修改了测试代码
- build: 表示修改了编译配置文件
- chore: 无 src 或 test 的操作
- revert: 回滚操作
[可选的作用域]
: 是为了描述 此次 commit 影响的范围,比如: route, component, utils, build, api, website, docs
<描述>
: 此次提交的简短描述
[可选的正文]
: 此次提交的详细描述,描述为什么修改,做了什么样的修改,以及开发的思路等等,输入 \n
换行
[可选的页脚]
: 主要写下面2种
- Breaking changes: 在可选的正文或脚注的起始位置带有 BREAKING CHANGE: 的提交,表示引入了破坏性变更(这和语义化版本中的 MAJOR 相对应)。
- Closed issues: 罗列此次提交修复的 bug,如 fixes issue #110
两种形式安装
全局安装
npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
全局模式下, 需要 ~/.czrc 配置文件, 为 commitizen 指定 Adapter
执行
git cz
项目级安装
npm install -D commitizen cz-conventional-changelog
package.json中配置:
"script":{"commit":"git-cz"},
"config":{"commitizen":{"path":"node_modules/cz-conventional-changelog"}}
执行
npm run commit
standard-version: 自动生成 CHANGELOG
同样可以有 2 种安装形式,这里只介绍项目级安装,接下来的介绍也都以此为例。
npm i -S standard-version
package.json 配置:
"scirpt":{"release":"standard-version"}
执行
npm run release
若全局安装,可直接使用 standard-version 命令,其作用等同于npm run release,下面不再赘述
standard-version 介绍
选项:
--release-as, -r Specify the release type manually (like npm version <major|minor|patch|1.1.0>) [字符串]
// major: 1.0.0 -> 2.0.0, minor: 1.0.0 -> 1.1.0, patch : 1.0.0 -> 1.0.1
--prerelease, -p make a pre-release with optional option value to specify a tag id [字符串]
--infile, -i Read the CHANGELOG from this file [默认值: "CHANGELOG.md"]
--message, -m Commit message, replaces %s with new version [字符串] [默认值: "chore(release): %s"]
--first-release, -f Is this the first release? [布尔] [默认值: false]
--sign, -s Should the git commit and tag be signed? [布尔] [默认值: false]
--no-verify, -n Bypass pre-commit or commit-msg git hooks during the commit phase [布尔] [默认值: false]
--commit-all, -a Commit all staged changes, not just files affected by standard-version [布尔] [默认值: false]
--silent Don't print logs and errors [布尔] [默认值: false]
--tag-prefix, -t Set a custom prefix for the git tag to be created [字符串] [默认值: "v"]
--scripts Provide scripts to execute for lifecycle events (prebump, precommit, [默认值: {}]
--skip Map of steps in the release process that should be skipped [默认值: {}]
--dry-run See the commands that running standard-version would run [布尔] [默认值: false]
常用发布命令
// 初次发布版本
npm run release --first-release
// 添加版本信息和指定发布版本等级
npm run release -m "Commit message" -r minor
// 确认发布,npm publish 发布到 npm
git push --follow-tags origin master && npm publish