书写良好的 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 这样的功能来自动帮我们检查一样。
联系我们

邮箱 626512443@qq.com
电话 18611320371(微信)
QQ群 235681453

Copyright © 2015-2022

备案号:京ICP备15003423号-3