一个计算机技术爱好者与学习者

0%

好好学Git：更好的Git提交信息

发表于 更新于 分类于 ，

1. 还可以更好

使用git很多年，也提交了很多代码，自以为使用习惯良好。因为每次提交代码，我都会在Git提交信息（git commit message）中说明清楚修改的内容。但是，偶然间读到一些关于commit message的文章，才发现还有很多进步的空间。

本文就来学习一下编写更高质量的提交信息，主要参考：

2. 约定式提交

2.1. 约定式提交简介

约定式提交规范是一种基于提交消息的轻量级约定。它提供了一组用于创建清晰的提交历史的简单规则；这使得编写基于规范的自动化工具变得更容易。 这个约定与 SemVer 相吻合， 在提交信息中描述新特性、bug 修复和破坏性变更。

约定式提交优点：

  • 自动化生成 CHANGELOG。
  • 基于提交的类型，自动决定语义化的版本变更。
  • 向同事、公众与其他利益关系者传达变化的性质。
  • 触发构建和部署流程。
  • 让人们探索一个更加结构化的提交历史，以便降低对你的项目做出贡献的难度。

2.2. 约定式提交结构

约定式提交说明的结构如下所示：

1
2
3
4
5
<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的脚注]

提交方法：

1
2
3
4
5
6
7
git commit -m "
dquote> <类型>[可选的作用域]: <描述>
dquote>
dquote> [可选的正文]
dquote>
dquote> [可选的脚注]
dquote> "

2.3. 约定式提交常用类型

  • fix: 在代码库中修复了一个 bug（这和语义化版本中的 PATCH 相对应）。
  • feat: 在代码库中新增了一个功能（这和语义化版本中的 MINOR 相对应）。
  • docs: 文档相关的改动。
  • refactor: 重构
  • improvement: 性能提升
  • test: 测试用例修改
  • style: 代码格式修改，注意不是 css 修改
  • revert: 回退
  • chore: 日常的小任务，比如构建流程，依赖管理。
  • misc: 对于那些难以分类的提交，可以使用misc（Miscellaneous的缩写，意为“杂项”）标签。
  • 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.4. 约定式提交参考项目

  • 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
2
[commit]
template = ~/.gitmessage

2、新建 ~/.gitmessage ，内容为

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# head: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore, misc
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer: 
# - Include a link to the ticket, if any.
# - BREAKING CHANGE
#

3、使用提示

1
git commit

3.2. commitizen

参考 commitizen/cz-cli 。