- 服务端开发/管理
- 书写良好的 commit message
今天来说说如何书写好的 commit message。
Commit message 大家应该每天都在写,每次使用 Git 提交代码时,我们都会在执行 git commit 命令时附带上一句话来简要描述此次提交的改动。
Commit message 看似简单,作用却很重要。在阅读代码时,可以通过 commit message 了解到作者编写某行代码时的背景;调查 bug 时可以通过搜索 commit message 快速定位相关的提交记录。
那么什么样的 commit message 才算好的 commit message 呢?
开源社区已经为我们总结出了一套名为 [Conventional Commits](https://conventionalcommits.org/#conventional-commits-100-beta2 "Conventional Commits") 的书写规范。很多流行的开源项目都使用了这套规范,如 Karma,Angular 等。其规定的格式如下:
[optional scope]:
[optional body]
[optional footer]
下面我们分别来介绍一下其中的各个组成部分:
`type` :用于表明我们这次提交的改动类型,是新增了功能?还是修改了测试代码?又或者是更新了文档?开源社区目前总结出了以下 11 种类型:
- build:主要目的是修改项目构建系统(例如 glup,webpack,rollup 的配置等)的提交
- ci:主要目的是修改项目继续集成流程(例如 Travis,Jenkins,GitLab CI,Circle等)的提交
- docs:文档更新
- feat:新增功能
- fix:bug 修复
- perf:性能优化
- refactor:重构代码(既没有新增功能,也没有修复 bug)
- style:不影响程序逻辑的代码修改(修改空白字符,补全缺失的分号等)
- test:新增测试用例或是更新现有测试
- revert:回滚某个更早之前的提交
- chore:不属于以上类型的其他类型
`optional scope`:一个可选的修改范围。用于标识此次提交主要涉及到代码中哪个模块。根据项目实际情况填写即可,最好在项目中规定好模块列表,保持一致性。
`description`:一句话描述此次提交的主要内容,做到言简意赅。
`optional body` 和 `optional footer` 通常我们都不会用到,此处不再赘述。
介绍完了格式,让我们来看看真实世界中符合该规范的 commit message 长什么样子吧。
以 Angular 为例,来看看它最新的提交历史:
是不是很整洁?
现在规范是有了,但是还需要一个工具自动帮我们检测我们编写的 commit message 是否真的符合规范。这就好比是我们创建了一套 JavaScript 的语法规范,还需要 ESLint 这样的功能来自动帮我们检查一样。