1 概述
本文主要用于总结自己的一套 Git Commit Message。
1.1 Git Commit Message是什么?
每次基于Git提交代码，都要写 Commit message（提交说明），否则就不允许提交。
$ git commit -m "hello world"
-m参数 : 指定 commit mesage
1.2 规范的提出背景
-
软件工程团队多人协作时，commit 混乱不堪，让人头痛————需要统一化、规范化。
Git每次提交代码都需要写commit message，否则就不允许提交。
一般来说，commit message应该清晰明了，说明本次提交的目的，具体做了什么操作……但是在日常开发中，大家的commit message千奇百怪，中英文混合使用、fix bug等各种笼统的message司空见怪，这就导致后续代码维护成本特别大，有时自己都不知道自己的fix bug修改的是什么问题。
基于以上这些问题，我们希望及早约束开发者的git commit message，让规范更好的服务于质量，提高大家的研发效率。 -
commit message 是软件工程规范化、软件质量保保障的重要组成部分
随着工作年限和项目经验的逐步加深，越发感受到这一点。
- commit message 应该如何写才更清晰明了？
本文总结下在git commit规范建设上的实践，规定了commit message的格式，避免不规范的代码提交。
1.3 规范的好处
git commit到底有哪些好处呢？
- Change Log : 便于软件工程师之间对提交历史进行追溯，了解发生了什么情况。提供更多的历史信息，方便快速浏览、检索、问题溯源。
下面的命令显示上次发布后的变动，每个commit占据一行。你只看行首，就知道某次 commit 的目的。
git log <last tag> HEAD --pretty=format:%s
- 可以过滤某些commit（比如文档改动），便于快速查找信息。如，下面的命令仅仅显示本次发布新增加的功能。
$ git log <last release> HEAD --grep feature
- More Clear: 一旦约束了commit message，意味着我们将慎重的进行每一次提交，不能再一股脑的把各种各样的改动都放在一个git commit里面，这样一来整个代码改动的历史也将更加清晰。
Change Log 是发布新版本、问题溯源时，用来说明与上一个版本差异的文档，详见后文。
- Auto : 格式化的commit message才可以用于自动化输出Change log。
2 规范建设
2.1 规范梳理的历程
-
初期阿里巴巴在互联网上搜索了大量有关 git commit规范 的资料，但只有 Angular 规范是目前使用最广的写法，比较合理和系统化，并且有配套的工具（IDEA就有插件支持这种写法）。
-
最后，综合阿里巴巴高德地图相关部门已有的规范总结出了一套git commit规范。
-
本文基于 阿里云开发者 的 alibaba commit message 规范之上，结合个人的工作实际情况，加以了改进。
2023.2.20
2.2 commit message 规范格式
[<type>:<systemScope>][<project>#<taskId/bugId/issueId>] : <subject>
2.2.1 type(必须)
- type(必须) : 用于说明git commit的类别，只允许使用下面的标识。
- init : 初始化相关(工程、系统)
- feat : 新功能（feature）
- fix/to : 修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。
- fix : 产生diff并自动修复此问题。适合于一次提交直接修复问题
- to : 只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix
- docs : 文档（documentation）。
- style : 格式（不影响代码运行的变动）。
- refactor : 重构（即不是新增功能，也不是修改bug的代码变动）。
- boost/perform : 优化相关，比如提升性能、体验。
- test : 测试相关
- chore / cicd / build : 构建过程或辅助工具的变动
- revert : 回滚到上一个版本。
- version : (本工程的)版本管理、版本发布、源代码相关（含：依赖组件版本管理）
- merge : 代码合并。
- sync : 同步主线或分支的Bug。
- dependency : 依赖组件的变更
2.2.2 systemScope(可选)
- systemScope(可选) : scope用于说明 commit 影响的系统范围，比如数据层、控制层、视图层等等，视项目不同而不同。
例如在Angular，可以是但不限于：
- boot / config : 系统启动相关 / 系统配置相关
- compile : 编译时
- location : 本地
- browser / view / ui : 浏览器 / 页面 / 系统界面
- server : 服务器端
- api : 接口
- controller : 接口的控制器层
- service : service层
- dao : dao层
- common : 公共包
如果你的修改影响了不止一个scope，你可以使用*代替。
2.2.3 project(可选)
- project(可选) : project说明 commit 影响的业务项目范围
例如：VHR / TSP / GATEWAY / ...
2.2.4 subject(必须)
- subject(必须) : subject是commit目的的简短描述，不超过50个字符。
建议使用中文（感觉中国人用中文描述问题能更清楚一些）。
结尾不加句号或其他标点符号。
2.2.5 小结/样例
根据以上规范git commit message将是如下的格式
[fix:api][vhr#BUG@34531]: 修复用户查询缺少username属性
备注：修复VHR项目中BUG为34531的接口，修复用户查询缺少username属性
[feature:api][rfh#TASK@453]: 用户查询接口开发
备注：修复rfh项目中TASK为453的接口：用户查询接口开发
3 延伸：基于WebHook的自动化约束与监控
建议：先把规范用起来，再来思考、研究这些工具较为妥当。不要工具、方法论一大堆，却没有真正付诸实践。
- 服务注册：服务注册主要完成代码库相关信息的添加。
- 重复校验：防止merge request再走一遍验证流程。
- 消息告警：对不符合规范以及大代码量提交、删除文件等操作发送告警消息。
- DB：存项目信息和git commit信息便于后续统计commit message规范率。
webhook是作用于代码库上的，用户提交git commit，push到仓库的时候就会触发webhook，webhook从用户的commit信息里面获取到commit message，校验其是否满足git commit规范，如果不满足就发送告警消息；如果满足规范，调用gitlab API获取提交的diff信息，验证提交代码量，验证是否有重命名文件和删除文件操作，如果存在以上操作还会发送告警消息，最后把所有记录都入库保存。