git是当初市面上最风行的版本控制工具，书写良好的commit message能大大提高代码保护的效率。然而在日常开发中因为短少对于commit message的束缚，导致填写内容随便、品质参差不齐，可读性低亦难以保护。在我的项目中引入commit message标准已是火烧眉毛。

用什么标准？

当初市面上比拟风行的计划是约定式提交标准（Conventional Commits），它受到了Angular提交准则的启发，并在很大水平上以其为根据。约定式提交标准是一种基于提交音讯的轻量级约定。它提供了一组用于创立清晰的提交历史的简略规定；这使得编写基于标准的自动化工具变得更容易。这个约定与SemVer相吻合，在提交信息中形容新个性、bug 修复和破坏性变更。它的 message 格局如下:

<类型>[可选的作用域]: <形容>[可选的注释][可选的脚注]

Quick Start

1.全局装置commitizen & cz-conventional-changelog

commitizen是一个撰写合格commit message的工具，用于代替git commit 指令，而cz-conventional-changelog适配器提供conventional-changelog规范（约定式提交规范）。基于不同需要，也能够应用不同适配器。

npm install -g commitizen cz-conventional-changelogecho '{ "path": "cz-conventional-changelog" }' > ~/.czrc

装置结束后，可间接应用git cz来取代git commit。

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

2.我的项目内装置commitlint & husky

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

Use npmnpm i -D husky @commitlint/config-conventional @commitlint/cliUse yarnyarn add husky @commitlint/config-conventional @commitlint/cli -D

commitlint只能做格局标准，无奈涉及内容。对于内容品质的把控只能靠咱们本人。

3. 增加相应配置

创立commitlint.config.js

# In the same path as package.jsonecho 'module.exports = {extends: ["@commitlint/config-conventional"]};' > ./commitlint.config.js引入husky# package.json...,"husky": {    "hooks": {      "commit-msg": "commitlint -e $GIT_PARAMS"    }}
4. 应用

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

1.Select the type of change that you're committing 抉择改变类型 (<type>)2.What is the scope of this change (e.g. component or file name)? 填写改变范畴 (<scope>)3.Write a short, imperative tense description of the change: 写一个精简的形容 (<subject>)4.Provide a longer description of the change: (press enter to skip) 对于改变写一段长形容 (<body>)5.Are there any breaking changes? (y/n) 是破坏性批改吗？默认n (<footer>)6.Does this change affect any openreve issues? (y/n) 改变修复了哪个问题？默认n (<footer>)

生成的commit message格局如下：

<type>(<scope>): <subject><BLANK LINE><body><BLANK LINE><footer>

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

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

Commit message标准在rrd-fe落地应用状况

针对团队目前应用的状况，咱们探讨后拟定了commit message每一部分的填写规定。

1. type

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

# 次要typefeat:     减少新性能fix:      修复bug# 非凡typedocs:     只改变了文档相干的内容style:    不影响代码含意的改变，例如去掉空格、扭转缩进、增删分号build:    结构工具的或者内部依赖的改变，例如webpack，npmrefactor: 代码重构时应用revert:   执行git revert打印的message# 暂不应用typetest:     增加测试或者批改现有测试perf:     进步性能的改变ci:       与CI（继续集成服务）无关的改变chore:    不批改src或者test的其余批改，例如构建过程或辅助工具的变动

当一次改变包含次要type与非凡type时，对立采纳次要type。

2. scope

scope也为必填项，用于形容改变的范畴，格局为我的项目名/模块名，例如：node-pc/common rrd-h5/activity，而we-sdk不需指定模块名。如果一次commit批改多个模块，倡议拆分成屡次commit，以便更好追踪和保护。

3. body

body填写详细描述，次要形容改变之前的状况及批改动机，对于小的批改不作要求，然而重大需要、更新等必须增加body来作阐明。

4. break changes

break changes指明是否产生了破坏性批改，波及break changes的改变必须指明该项，相似版本升级、接口参数缩小、接口删除、迁徙等。

5. affect issues

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

填写形式例如：

re #JIRA_IDfix #JIRA_ID

示例

  • 残缺的commit message示例

  • 相应的git log

如果你喜爱这篇文章，心愿能动动小手点个在看与转发反对一波。

人人贷大前端技术核心
juejin.im/post/5d0b3f8c6fb9a07ec07fc5d0