如何优雅的在 Git 上 Commit 以及自动生成版本变更日志Change log
你有没有在开发工作中抱怨别人提交的乱七八糟?也不写每次提交是因为什么干了什么?如果在Github上为开源项目贡献代码的时候,提交没有按照人家的模板要求,你的合并请求还是不被接受的。而且杂乱无章的Commit不但会影响其他人,在版本发布的时候,版本变更日志应该是可以自动生成的,但是没有按规定写的Commit就无法被自动统计进去,所以今天我就写一下如何优雅的在 Git 上 Commit 以及自动生成版本变更日志Change log。这篇文章只关注 Commit 的姿势,Commit命令等其他的暂不讨论
我们首先找一个比较优秀的来看一看人家的Commit姿势是什么样的,我就以 Vue 团队的Github仓库举例:https://github.com/vuejs/vue/commits/dev

可以看出每次Commit都清晰明了,而且格式都是统一的标准,其实社区有多种 Commit message 的写法规范,咱们就看最常见的使用最广的写法
Commit message 的格式
Commit message 包括三个部分:Header,Body 和 Footer。其中,Header 是必需的,Body 和 Footer 可以省略。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
Header
Header部分只有一行,包括三个字段:type(必需)、scope(可选)和subject(必需)。
type用于说明 commit 的类别,只允许使用下面7个标识。
feat:新功能(feature)
fix:修补bug
docs:文档(documentation)
style: 格式(不影响代码运行的变动)
refactor:重构(即不是新增功能,也不是修改bug的代码变动)
test:增加测试
chore:构建过程或辅助工具的变动
如果type为feat和fix,则该 commit 将肯定出现在 Change log 之中。其他情况(docs、chore、style、refactor、test)由你决定,要不要放入 Change log,不过建议是不要。
scope用于说明 commit 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。
subject是 commit 目的的简短描述,不超过50个字符。
以动词开头,使用第一人称现在时,比如change,而不是changed或changes
第一个字母小写
结尾不加句号(.)
Body
Body 部分是对本次 commit 的详细描述,可以分成多行。有两个注意点:使用第一人称现在时,比如使用change而不是changed或changes;应该说明代码变动的动机,以及与以前行为的对比。Body部分是可以不写的。
Footer
Footer 部分只用于两种情况:
(1)不兼容变动
如果当前代码与上一个版本不兼容,则 Footer 部分以BREAKING CHANGE开头,后面是对变动的描述、以及变动理由和迁移方法。
(2)关闭 Issue
如果当前 commit 针对某个issue,那么可以在 Footer 部分关闭这个 issue 只需要写:Closes #12,这个#12就是Issue的编号
总结
如果你新增一个功能,那么最简单的应该这样写:feat: 新增XXX产品模块
如果你修复一个BUG,那么最简单的应该这样写:fix: 登陆验证码失效问题
如果你修改一个文档,那么最简单的应该这样写:docs: 编辑了账户权限文档
以此类推的格式,这样的好处是一眼就能看出你做了什么操作,方面统计,下面咱们再说自动生成版本变更日志Change log。
生成 Change log
如果你的所有 Commit 都符合格式要求,那么发布新版本时, Change log 就可以用脚本自动生成。生成的文档包括以下三个部分:
New features
Bug fixes
Breaking changes.
conventional-changelog 就是生成 Change log 的工具,运行下面的命令即可。没有安装 npm 的同学先安装一下 npm。
npm install -g conventional-changelog
$ cd my-project
$ conventional-changelog -p angular -i CHANGELOG.md -w
上面命令不会覆盖以前的 Change log,只会在CHANGELOG.md的头部加上自从上次发布以来的变动。如果你想生成所有发布的 Change log,要改为运行下面的命令。
conventional-changelog -p angular -i CHANGELOG.md -w -r 0
商业用途请联系作者获得授权。
版权声明:本文为博主「任霏」原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接及本声明。
相关推荐
猜你还喜欢这些内容,不妨试试阅读一下评论与留言
以下内容均由网友提交发布,版权与真实性无法查证,请自行辨别。微信订阅号
扫码关注「任霏博客」微信订阅号- 你写得非常清晰明了,让我很容易理解你的观点。
- 感谢分享!拿走了~
- 您是说 UCClient 类接收来自Discuz的UCenter的消息吧,请求是来自 Discuz 的 UCenter吗?code 为 null 说明请求URL地址中没有 code 参数 (?code=xxx) ,确定是 UCenter 发起的请求吗?
- String code = request.getParameter("code"); code一直是null 这是为什么啊
- 你好,我想问一下如果是分析型的数据库要怎么制作docker镜像呢 是修改V008R003C002B0320版本号吗
- 可以的,我也正在开发分享的程序,可以邮件或群联系我都可以,关于页面里有联系方式:https://www.renfei.net/page/about 。
- 有破解软件的需要可以私下联系您吗?
- 您好,手机APP只是个客户端,用于数据呈现展示,数据均保存在服务器上,只留个APP没有任何用处,无能为力哦。
- 老哥 看你弄了这么多软件好厉害啊。 我有个软件 我买过几个小会员 没用几天 然后商家跑路了,软件服务器关闭了,连不上去 用不了。 你能做成一个打补丁版本可以本地用的么? 方便看下么?https://haodezhe.lanzouw.com/iD0f30h9joza 谢谢老哥!
- 您好,由于版权投诉和我国知识产权法的完善,我已经下架所有破解软件的下载链接了。
- 生花妙笔信手来 – 基于 Amazon SageMaker 使用 Grounded-SAM 加速电商广告素材生成 [1]
- github.renfei.net 不再完整代理 Github 页面改为代理指定文件
- 优雅的源代码管理(三):本地优雅的使用 Git Rebase 变基
- 优雅的源代码管理(二):Git 的工作原理
- 优雅的源代码管理(一):版本控制系统 VCS(Version Control System)与软件配置管理 SCM(Software Configuration Management)
- ChatGPT 开发商 OpenAI 买下极品域名 AI.com
- 火爆的 AI 人工智能 ChatGPT 国内注册教程、使用方式和收费标准
- 解决 SpringCloud 中 bootstrap.yml 不识别 @activatedProperties@ 参数
- Cron表达式书写教程搞定Linux、Spring、Quartz的定时任务
- 阿里云香港可用区C发生史诗级故障