如何优雅的在 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发生史诗级故障