Git commit提交规范与`Changelog`生成

Git commit规范与Changelog生成

良好的Git commit 规范优势

• 加快Code Review的流程
• 根据Git Commit的元数据生成Changelog
• 后续维护者可以知道Feature被修改的原因

技术方案：

统一团队Git commit日志标准，便于后续代码review和版本发布

使用Git commit日志作为基本规范

• 提交类型限制为:feat,fix,docs,style,rrefactor,perf,test,chore,revert等
• 提交信息分为俩部分，标题（首字母不大写，末尾不i要标点）、主题内容（正常的描述信息即可）

日志提交时友好的类型选择提示

• 使用commitize工具

不符合要求格式的日志拒绝提交的保障机制

• 使用validata-commit-msg工具
• 需要同时在客户端、gitlab serverhook做

统一Changelog文档信息生成

• 使用conventional-changelog-cli工具

提交格式要求

():

对格式的说明如下：

• type:代表某次提交的类型，比如时修复一个bug还是增加一个新的feature

• feat：新功能（feature）

• fix：修补bug

• docs：文档（documentation）

• style： 格式（不影响代码运行的变动）

• refactor：重构（即不是新增功能，也不是修改bug的代码变动）

• test：增加测试

• chore：构建过程或辅助工具的变动

• revert:回滚到上一个版本

本地开发阶段增加precommit钩子

npm i husky --save-dev

通过commitmsg钩子校验信息

"scripts":{
	"commitmsg":"validata-commit-msg",
	"changelog":"conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
},
"devDependencies":{
	"validata-commit-msg":"^2.11.1",
	"conventional-changelog-cli":"^1.2.0",
	"husky":"^0.13.1"
}

开源项目版本信息案例

软件的版本通常由三位组成，形如：X.Y.Z

版本时严格递增的，例如：16.2.0==>12.3.0==>12.3.1

在发布重要版本时，可以发布alpha,rc等先行版本

遵守semver规范的优势

优势：

• 避免出现循环依赖
• 依赖冲突减少

语义化版本（Semantic Versioning） 规范格式

主版本号：当你做了不兼容的API修改 ==》 X

次版本号：当你做了向下兼容的功能性新增==》Y

修订号：当你做了向下兼容的问题修正==》Z

先行版本号

• alpha:内部测试版
• beta：测试版
• rc：发行候选版本