更好的 git commit message

还可以更好

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

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

• Commit message 和 Change log 编写指南
• 优雅的提交你的 Git Commit Message
• Conventional Commits
• 你可能已经忽略的 git commit 规范

约定式提交

简介

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

约定式提交优点：

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

使用说明

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

<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的脚注]

提交方法：

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）。
可以为提交类型添加一个围在圆括号内的作用域，以为其提供额外的上下文信息。例如：

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 ，添加

[commit]
template = ~/.gitmessage

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

# 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 。