共计 2839 个字符，预计需要花费 8 分钟才能阅读完成。
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-changelog
echo '{"path":"cz-conventional-changelog"}' > ~/.czrc装置结束后，可间接应用 git cz 来取代 git commit。
全局模式下，须要 ~/.czrc 配置文件, 为 commitizen 指定 Adapter。
2. 我的项目内装置 commitlint & husky
commitlint 负责用于对 commit message 进行格局校验，husky 负责提供更易用的 git hook。
Use npm
npm i -D husky @commitlint/config-conventional @commitlint/cli
Use yarn
yarn add husky @commitlint/config-conventional @commitlint/cli -Dcommitlint 只能做格局标准，无奈涉及内容。对于内容品质的把控只能靠咱们本人。
3. 增加相应配置
创立 commitlint.config.js
# In the same path as package.json
echo '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 暂不应用。
# 次要 type
feat: 减少新性能
fix: 修复 bug
# 非凡 type
docs: 只改变了文档相干的内容
style: 不影响代码含意的改变，例如去掉空格、扭转缩进、增删分号
build: 结构工具的或者内部依赖的改变，例如 webpack，npm
refactor: 代码重构时应用
revert: 执行 git revert 打印的 message
# 暂不应用 type
test: 增加测试或者批改现有测试
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_ID
fix #JIRA_ID示例
- 残缺的 commit message 示例
- 相应的 git log
如果你喜爱这篇文章，心愿能动动小手点个在看与转发反对一波。
人人贷大前端技术核心
juejin.im/post/5d0b3f8c6fb9a07ec07fc5d0
