git是现在市面上最流行的版本控制工具，书写良好的commit message能大大提高代码维护的效率。但是在日常开发中由于缺少对于commit message的约束，导致填写内容随意、质量参差不齐，可读性低亦难以维护。在项目中引入commit message规范已是迫在眉睫。

现在市面上比较流行的方案是 约定式提交规范（ ConventionalCommits），它受到了 Angular提交准则的启发，并在很大程度上以其为依据。约定式提交规范是一种基于提交消息的轻量级约定。它提供了一组用于创建清晰的提交历史的简单规则；这使得编写基于规范的自动化工具变得更容易。这个约定与 SemVer相吻合，在提交信息中描述新特性、bug 修复和破坏性变更。它的 message 格式如下:

commitizen是一个撰写合格 commit message的工具，用于代替 git commit 指令，而 cz-conventional-changelog适配器提供conventional-changelog标准（约定式提交标准）。基于不同需求，也可以使用不同适配器。

安装完毕后，可直接使用 git cz来取代 git commit。

全局模式下，需要 ~/.czrc 配置文件, 为 commitizen指定 Adapter。

commitlint负责用于对 commit message进行格式校验， husky负责提供更易用的 git hook。

Usenpm

Useyarn

commitlint只能做格式规范，无法触及内容。对于内容质量的把控只能靠我们自己。

创建 commitlint.config.js

引入 husky

执行 git cz进入interactive模式，根据提示依次填写

生成的commit message格式如下：

填写完毕后， husky会调用 commitlint对message进行格式校验，默认规定 type及 subject为必填项。

任何 git commit指令的 option都能用在 git cz指令上, 例如 git cz-a

针对团队目前使用的情况，我们讨论后拟定了 commit message每一部分的填写规则。

type为必填项，用于指定commit的类型，约定了 feat、 fix两个 主要type，以及docs、style、build、refactor、revert五个 特殊type， 其余type暂不使用。

当一次改动包括 主要type与 特殊type时，统一采用 主要type。

scope也为必填项，用于描述改动的范围，格式为项目名/模块名，例如：node-pc/common rrd-h5/activity，而 we-sdk不需指定模块名。如果一次commit修改多个模块，建议拆分成多次commit，以便更好追踪和维护。

body填写详细描述，主要描述 改动之前的情况及 修改动机，对于小的修改不作要求，但是重大需求、更新等必须添加body来作说明。

breakchanges指明是否产生了破坏性修改，涉及break changes的改动必须指明该项，类似版本升级、接口参数减少、接口删除、迁移等。

affect issues指明是否影响了某个问题。例如我们使用jira时，我们在 commit message中可以填写其影响的 JIRA_ID，若要开启该功能需要先打通 jira与 gitlab。参考文档：docs.gitlab.com/ee/user/pro…

填写方式例如：

完整的commit message示例

相应的git log

最后惯例，欢迎大家star我们的人人贷大前端团队博客，所有的文章还会同步更新到知乎专栏 和 掘金账号，我们每周都会分享几篇高质量的大前端技术文章。如果你喜欢这篇文章，希望能动动小手给个赞。

人人贷大前端技术中心

juejin.im/post/5d0b3f8c6fb9a07ec07fc5d0