1. 还可以更好
使用git很多年,也提交了很多代码,自以为使用习惯良好。因为每次提交代码,我都会在git commit message中说明清楚修改的内容。但是,偶然间读到一些关于commit message的文章,才发现还有很多进步的空间。
本文就来学习一下编写更高质量的提交信息,主要参考:
- Commit message 和 Change log 编写指南
- 优雅的提交你的 Git Commit Message
- Conventional Commits
- 你可能已经忽略的 git commit 规范
2. 约定式提交
2.1. 简介
约定式提交规范是一种基于提交消息的轻量级约定。它提供了一组用于创建清晰的提交历史的简单规则;这使得编写基于规范的自动化工具变得更容易。 这个约定与 SemVer 相吻合, 在提交信息中描述新特性、bug 修复和破坏性变更。
约定式提交优点:
- 自动化生成 CHANGELOG。
- 基于提交的类型,自动决定语义化的版本变更。
- 向同事、公众与其他利益关系者传达变化的性质。
- 触发构建和部署流程。
- 让人们探索一个更加结构化的提交历史,以便降低对你的项目做出贡献的难度。
2.2. 使用说明
提交说明的结构如下所示:
1 | <类型>[可选的作用域]: <描述> |
提交方法:
1 | git commit -m " |
提交说明包含了下面的结构化元素,以向类库使用者表明其意图:
类型 | 描述 |
---|---|
fix | 在代码库中修复了一个 bug(这和语义化版本中的 PATCH 相对应)。 |
feat | 在代码库中新增了一个功能(这和语义化版本中的 MINOR 相对应)。 |
docs | 文档相关的改动。 |
refactor | 重构 |
improvement | 性能提升 |
test | 测试用例修改 |
style | 代码格式修改, 注意不是 css 修改 |
chore | 其他修改, 比如构建流程, 依赖管理。 |
Close | 在可选的正文或脚注的起始位置,关闭issue |
BREAKING CHANGE | 在可选的正文或脚注的起始位置,表示引入了破坏性 API 变更(这和语义化版本中的 MAJOR 相对应)。 破坏性变更可以是任意类型提交的一部分。 |
以上类型都是可选的,其他类型也被允许,根据需要定义项目的提交规范就好。并且在语义化版本中没有隐式的影响(除非他们包含 BREAKING CHANGE)。 | |
可以为提交类型添加一个围在圆括号内的作用域,以为其提供额外的上下文信息。例如: |
1 | feat(parser): adds ability to parse arrays. |
可以在类型/作用域前缀之后,:
之前,附加 !
字符,以进一步提醒注意破坏性变更。当有 !
前缀时,正文或脚注内必须包含 BREAKING CHANGE: description
约定式提交和 SemVer 的关联:fix 类型提交应当对应到 PATCH 版本。feat 类型提交应该对应到 MINOR 版本。带有 BREAKING CHANGE 的提交不管类型如何,都应该对应到 MAJOR 版本。
2.3. 参考
- yargs:广受欢迎的命令行参数解析器。
- istanbuljs:一套为 JavaScript 测试生成测试覆盖率的开源工具和类库。
- massive.js:一个用于 Node 和 PostgreSQL 的数据访问类库。
- electron:用 JavaScript、HTML 和 CSS 构建跨平台应用。
- scroll-utility:一个居中元素和平滑动画的滚屏工具包实例。
- Blaze UI:无框架开源 UI 套件。
- Monica:一个开源的人际关系管理系统。
- mhy:一个零配置、开箱即用的、多用途工具箱与开发环境。
- sharec:一个用于模板和配置文件版本化的极简工具。
3. 提交帮助工具
3.1. git commit提示
1、修改 ~/.gitconfig
,添加
1 | [commit] |
2、新建 ~/.gitmessage
,内容为
1 | # head: <type>(<scope>): <subject> |
3、使用提示git commit
3.2. commitizen
参考 commitizen/cz-cli 。