0%

git commit message进阶

还可以更好

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

本文就来学习一下编写更高质量的提交信息,主要参考 Commit message 和 Change log 编写指南优雅的提交你的 Git Commit MessageConventional Commits

约定式提交

简介

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

约定式提交优点:

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

使用说明

提交说明的结构如下所示:

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

[可选的正文]

[可选的脚注]

提交方法:

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

提交说明包含了下面的结构化元素,以向类库使用者表明其意图:

类型描述
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 版本。

参考

  • yargs:广受欢迎的命令行参数解析器。
  • istanbuljs:一套为 JavaScript 测试生成测试覆盖率的开源工具和类库。
  • massive.js:一个用于 Node 和 PostgreSQL 的数据访问类库。
  • electron:用 JavaScript、HTML 和 CSS 构建跨平台应用。
  • scroll-utility:一个居中元素和平滑动画的滚屏工具包实例。
  • Blaze UI:无框架开源 UI 套件。
  • Monica:一个开源的人际关系管理系统。
  • mhy:一个零配置、开箱即用的、多用途工具箱与开发环境。
  • sharec:一个用于模板和配置文件版本化的极简工具。

提交帮助工具

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
# - 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、使用提示
git commit

commitizen

参考 commitizen/cz-cli