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>(<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:发行候选版本
  • 2
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值