一、前言
在团队开发中，我们通常使用git来进行代码提交， 所以对于提交信息进行规范和约束是有必要的，一个规范的提交信息，可以让项目的维护或使用人员能够了解提交了哪些更改；在需要时可以看到一个清晰的历史提交记录；规范的提交记录还可自动生成并修改日志(CHANGELOG.MD)
二、约束提交规范
为了保证每一次的代码提交都是符合规范的，最好的方式就是通过工具来生成和校验;
`commitizen`是一个nodejs命令行用来格式化commit message工具，通过交互的方式，生成符合规范的git commit；
`husky` 是一个增强的 git hook 工具，借助husky在每次 commit 时执行 commitlint来检查我们输入的 message。
`commitlint` 检测提交commit提交记录是否符合规范
`lint-staged` 检查提交暂存区代码是否符合规范
安装流程
yarn global add commitizen
yarn global add conventional-changelog-cli // 生成变更记录
yarn global add standard-version // 进行版本管理自动化
commitizen init cz-conventional-changelog --yarn --dev --exact
配置命令
// packages.json
"config": {
"commitizen": {
"path": "cz-conventional-changelog"
}
}
"scripts": {
// 运行脚本在CHANGELOG.md 查看变更记录
"log": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0",
"release": "standard-version",
"release:beta": "standard-version --prerelease beta",
"release:alpha": "standard-version --prerelease alpha",
"release:major": "standard-version --release-as major",
"release:minor": "standard-version --release-as minor",
"release:patch": "standard-version --release-as patch"
}
安装完成后可以使用git cz 来代替git commit,然后根据提示一步步输入即可；
三、 自动版本管理和生成CHANGELOG
规范化的提交信息除了能很好描述项目的修改，还有一个很好的作用就是能根据提交记录来生成CHANGELOG.MD和自动生成版本号等功能。
standard-version
一个用于生成`CHANGELOG.md`和进行`SemVer(语义化版本号)`发版的命令行工具；
主要功能：
- 自动修改最新版本号，可以是`package.json`或者自定义一个文件
- 读取最新版本号，创建一个最新的`git tag`
- 根据提交信息，生成`CHANGELOG.md`
- 创建一个新提交包括 `CHANGELOG.md`和`package.json`
CHANGELOG.md 配置
standard-verstion 生成的CHANGELOG只会包含feat,fix,BREACK-CHANGE类型的提交记录，如果想记录其他类型的提交，需要根目录下创建一个名为 .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* 中显示
语义化版本控制(SemVer)
语义化的版本控制是由GitHub发起的一份用于规范版本号递增的规则；
版本格式
主版本号.次版本号.修订号，版本号递增规则如下：
- 主版本号(major)：当你做了不兼容的 API 修改，
- 次版本号(minor)：当你做了向下兼容的功能性新增，可以理解为Feature版本，
- 修订号(patch)：当你做了向下兼容的问题修正，可以理解为Bug fix版本。
先行版本号可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
先行版本
当即将发布大版本改动前，但是又不能保证这个版本的功能 100% 正常，这个时候可以发布先行版本：
- alpha: 内部版本
- beta: 公测版本
- rc: 候选版本(Release candiate)
比如：1.0.0-alpha.0,1.0.0-alpha.1,1.0.0-rc.0,1.0.0-rc.1等。
standard-version 会根据提交的信息类型来自动更改对应的版本号,如下:
- feat: 次版本(minor)+1
- fix: 修订号(patch) +1
- BREAK CHANGE: 主板号(marjor) +1
