Commit信息每个人都有每个人的风格，但是为了更好地管理分支及追溯问题，需要对Commit信息做规范化，保证每一次Commit的信息有较好的可读性；

可读性较差的Commit信息

FlinkStreamSQL Commit信息

错误一

多次提交，但是只是重构一个功能，这样提交会显得很多余，甚至’temp save’这种都能出现；
image.png

错误二

信息过于简单，不知道做了什么事，如果想知道为啥这么改，只能去找对应的redmine，这里还有个可修改的地方，opt应该写成style，因为是对代码风格的调整，并不影响实际执行的代码；
image.png

错误三

提交人不明确是谁，不利于后期追溯问题；
image.png

比较好的Commit信息

Flink Commit信息

Flink Commit信息的前缀比较标准统一，首先是能够知道此次提交做了什么事情，是增加测试还是bug修复，其二是能根据Commit信息追溯此次提交的依据；
image.png

明确地说明此次提交做了什么事，不需要在意信息的长短，只需要能够表达清楚，有必要时，可以附上简单的demo说明；
image.png

Hadoop Commit信息

Hadoop Commit信息较为整齐，模块+标号，因为Hadoop功能较多，所以Commit信息以功能模块做为划分，在可读性方面，略比Flink的稍差一些；
image.png

规范

FlinkStreamSQL Commit信息标准模仿Flink，做到统一规范，Commit信息不限制中英文

  1. [type-redmine]<module> msg

首先，需要表明此次Commit的类别

  1. 1. feat：表示是一个新功能（feature)
  2. 2. fix：hotfix，修补bug
  3. 3. docs：改动文档
  4. 4. style：修改代码风格及opt imports这些，不改动原有执行的代码
  5. 5. test：增加测试
  6. 6. chore：构建过程或辅助工具有所变动
  7. 7. refactor：重构代码

然后如果有对应的redmine，那么就附上对应的redmine编号

  1. [fix-31280]<core> 修复bigdecimal转decimal运行失败问题
  2. [feat-31372]<rdb> RDB结果表Upsert模式支持选择更新策略

如果是像单测、文档这种没有对应redmine的，就可以这么写

  1. [test]<mysql> add mysql test
  2. [docs]<mysql> 修复mysql文档错误
  3. [style]<mysql> 优化mysql代码及opt imports