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>(<scope>):<subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
对格式的说明如下:
-
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
:发行候选版本