前言

一直以来我的commit都写的像💩一样，完全凭感觉写，今天h3h3qaq师傅给我推荐了一篇阿里云的文章：如何规范你的Git commit？，立刻严肃学习😠

commit规范

一般来说commit是用来标识你这次改动是干什么的，比如你的commit内容是”修复了xxx的bug”，和你一起合作的人就明白——哦，原来他这次改动是为了修复bug。否则直接diff代码的话，代码量少可能还看的出来这人是想干什么，代码量一旦大起来就完全不知所云了。

一个标准的commit格式应当如下：

<type>(<scope>): <subject>

type 为必须项，用于说明git commit的类别(我之前很喜欢用update，感情这个是不规范的)：

• feat：新功能
  • 增加新功能，即新feature
• fix/to：修复bug，在其中又有两种不同的修复：
  • fix：产生diff并自动修复此问题，适合于一次提交直接修复问题
  • to：只产生diff不自动修复此问题，适合于多次提交，但最终修复问题时必须使用fix
• docs：文档
  • 关于文档document的变动
• style：格式
  • 不影响代码运行的变动，比如空格、缩进、分号之类的
• refactor：重构
  • 既不是新增功能，也不是修改bug的代码变动
• perf：优化相关
  • 比如提升性能、体验。
• test：增加测试
  • 新增或修改测试
• chore：构建过程或辅助工具的变动。
  • chore 指的是不属于功能 (feat)、修复 (fix)等范畴的日常维护性工作，比如构建过程、依赖管理、工具链、配置文件等方面的变动，不会影响业务逻辑或功能本身，因此就是一些日常杂务性的提交
• revert：撤销上一次提交
• merge：代码合并
• sync：用于分支同步

scope 是一个可选项，用于说明 commit 影响的范围，比如是某个具体的组件，如图表、仪表盘等等，如果修改影响了不止一个scope，可以使用*代替或者不使用 scope

subject 是最后一个必须选项，用于简短的描述本次commit的目的，一般不超过50个字符(如果超了github也会提示你最好commit不要写太长)，对于我们中国人一般写中文清晰点，不过感觉大伙还是更喜欢用英文😂，对于每次commit，结尾不加句号或其他标点符号，比如下面是两个标准的commit：

refactor(图表): 增加部分图表插件参数
fix(嵌入式): 嵌入式样式问题

可以看到一般来说冒号和后面的subject之间还有一个空格，这样也更好看一点。

真实案例

之前一直挖dataease，也挖出感情了😂，dataease作为一个20k star的超级明星项目，commit确实是极其规范的，我们就用dataease来学习真实的commit应该怎么写。

feat

https://github.com/dataease/dataease/commit/af17fe327533ad6da55c1f6fca515e20afb6b6fd

当新增功能时，我们就需要用到feat：

feat(图表): 基础条形图/柱状图支持点击阴影部分执行下钻、联动、跳转

fix/to

翻了翻dataease的commit，似乎没有to的用法，可能是阿里云团队内部的规范，这里就只举例fix的了：

https://github.com/dataease/dataease/commit/0a1dcf7194cb703ec539fd3758fd780c4f120199

修bug的时候需要用到fix：

fix(X-Pack): 阈值告警-动态时间小时粒度格式错误

docs

https://github.com/dataease/dataease/commit/c0a93a588942c00e3d5edc634e59f9b69b83ac45

有关文档的修改需要用到docs，但可以看到这里没有标出scope，可能因为有关文档的修改都是全局性的，所以没什么必要标出来：

docs: Add GitCode badge

style

https://github.com/dataease/dataease/commit/50ce5396e0a8113074b08b0ffaaaefafac6c5991

stype用于不影响代码运行的改动，看了看dataease的style commit，基本上都是用于格式的，比如字体、图片样式啥的

style(仪表板、数据大屏): 调整查询组件的文字大小范围

refactor

https://github.com/dataease/dataease/commit/1a835a11961440d9cb68a5d3cbc317ab2bd32645

按照规范的定义，refactor用于既不新增功能，也不修改bug的重构，但我看dataease这里好多refactor其实都能归类到fix或者feat上😂：

refactor(数据大屏): 保持比例填充展示模式优化

perf

https://github.com/dataease/dataease/commit/c607ca294a5a769c7226690952b136c527ef4ef2

perf用于优化相关，比如这里就是优化用户体验的：

perf(X-Pack): 阈值告警-优化告警内容模版

test

https://github.com/dataease/dataease/commit/c05f0f305cac1cc9f8750aa37bf4d8a26045fd15

test用于测试相关，可能由于测试一般用于整个项目，所以我看dataease的test commit都没用scope:

test: 国际化测试

chore

https://github.com/dataease/dataease/commit/d97dd802f6e45ef6a225a67cd85b1963e7e192f2

chore用于不影响业务逻辑的杂务性提交，比如dataease每个版本更新版本号都是用的chore：

chore: 升级版本号到 v2.10.11

revert

https://github.com/dataease/dataease/commit/5408f54c98d51e67eaf5e2434be2c6edd0adac67

revert用于代码回滚，可以看到dataease这里就是用revert+具体的改动：

revert: 屏蔽装饰组件

merge

https://github.com/dataease/dataease/commit/cee455d20d48b3b7368182c2ff81dd9063cc1b73

merge用于合并分支，基本上用的都是github默认的commit，不是按上面的格式来的：

Merge remote-tracking branch 'origin/dev-v2' into dev-v2

sync

搜了搜sync，在dataease的commit里没搜到，应该也是阿里云团队内部定义的，大伙一般都用的Merge