commit message 规范如下：

1
2
3
4
5

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

[可选的正文]

[可选的脚注]

Commit message 规范在 rrd-fe 落地使用情况

针对团队目前使用的情况，我们讨论后拟定了 commit message 每一部分的填写规则。大牛总结的 Git 使用技巧，这篇推荐大家看下。

\1. type

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 主要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。Git 的这个神技，学会爽歪歪~这篇推荐阅读。

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

参考文档：

https://docs.gitlab.com/ee/user/project/integrations/jira.html

扩展阅读

conventional commits 必读 介绍约定式提交标准。

https://www.conventionalcommits.org/zh/v1.0.0-beta.3/

Angular 规范 必读 介绍 Angular 标准每个部分该写什么、该怎么写。

https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines

@commitlint/config-conventional 必读 介绍 commitlint 的校验规则 config-conventional，以及一些常见 passes/fails 情况。

https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional