Git提交规范 ¶
Git是现在市面上最流行的版本控制工具，书写良好的commit message能大大提高代码维护的效率。但是在日常开发中由于缺少对于commit message的约束，导致填写内容随意、质量参差不齐，可读性低亦难以维护。在项目中引入commit message规范已是迫在眉睫。 用什么规范？
现在市面上比较流行的方案是约定式提交规范（Conventional Commits），它受到了Angular提交准则的启发，并在很大程度上以其为依据。约定式提交规范是一种基于提交消息的轻量级约定。它提供了一组用于创建清晰的提交历史的简单规则；这使得编写基于规范的自动化工具变得更容易。这个约定与SemVer相吻合，在提交信息中描述新特性、bug 修复和破坏性变更。它的 message 格式如下:
<类型>[可选的作用域]: <描述>
[可选的正文]
[可选的脚注]说明 ¶
针对团队目前使用的情况，我们讨论后拟定了commit message每一部分的填写规则。
1. type ¶
type为必填项，用于指定commit的类型，约定了 feat、fix两个 主要type，以及docs、style、build、refactor、revert五个 特殊type，其余type暂不使用。
feat: 增加新功能
fix: 修复bug
docs: 只改动了文档相关的内容
style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
refactor: 代码重构
revert: 撤销修改，执行git revert打印的message
test: 添加测试或者修改现有测试
perf: 提高性能的改动
ci: 与CI（持续集成服务）有关的改动
chore: 依赖更新/脚手架配置修改等
workflow：工作流改进2. scope ¶
scope也为必填项，用于描述改动的范围，格式为项目名/模块名，例如： sy-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