共计 3576 个字符，预计需要花费 9 分钟才能阅读完成。
简介： commit message 应该如何写才更清晰明了？团队开发中有没有遇到过让人头疼的 git commit？本文分享在 git commit 标准建设上的实际，规定了 commit message 的格局，并通过 webhook 在提交时进行监控，防止不标准的代码提交。
背景
Git 每次提交代码都须要写 commit message，否则就不容许提交。一般来说，commit message 应该清晰明了，阐明本次提交的目标，具体做了什么操作……然而在日常开发中，大家的 commit message 千奇百怪，中英文混合应用、fix bug 等各种抽象的 message 司空怪罪，这就导致后续代码保护老本特地大，有时本人都不晓得本人的 fix bug 批改的是什么问题。基于以上这些问题，咱们心愿通过某种形式来监控用户的 git commit message，让标准更好的服务于品质，进步大家的研发效率。
标准建设
标准梳理
初期咱们在互联网上搜寻了大量无关 git commit 标准的材料，但只有 Angular 标准是目前应用最广的写法，比拟正当和系统化，并且有配套的工具（IDEA 就有插件反对这种写法）。最初综合阿里巴巴高德地图相干部门已有的标准总结出了一套 git commit 标准。
commit message 格局
<type>(<scope>): <subject>type(必须)
用于阐明 git commit 的类别，只容许应用上面的标识。
feat：新性能（feature）。
fix/to：修复 bug，能够是 QA 发现的 BUG，也能够是研发本人发现的 BUG。
- fix：产生 diff 并主动修复此问题。适宜于一次提交间接修复问题
- to：只产生 diff 不主动修复此问题。适宜于屡次提交。最终修复问题提交时应用 fix
docs：文档（documentation）。
style：格局（不影响代码运行的变动）。
refactor：重构（即不是新增性能，也不是批改 bug 的代码变动）。
perf：优化相干，比方晋升性能、体验。
test：减少测试。
chore：构建过程或辅助工具的变动。
revert：回滚到上一个版本。
merge：代码合并。
sync：同步主线或分支的 Bug。
scope(可选)
scope 用于阐明 commit 影响的范畴，比方数据层、管制层、视图层等等，视我的项目不同而不同。
例如在 Angular，能够是 location，browser，compile，compile，rootScope，ngHref，ngClick，ngView 等。如果你的批改影响了不止一个 scope，你能够应用 * 代替。
subject(必须)
subject 是 commit 目标的简短形容，不超过 50 个字符。
倡议应用中文（感觉中国人用中文形容问题能更分明一些）。
- 结尾不加句号或其余标点符号。
- 依据以上标准 git commit message 将是如下的格局：
fix(DAO): 用户查问短少 username 属性
feat(Controller): 用户查问接口开发 以上就是咱们梳理的 git commit 标准，那么咱们这样标准 git commit 到底有哪些益处呢？
- 便于程序员对提交历史进行追溯，理解产生了什么状况。
- 一旦束缚了 commit message，意味着咱们将谨慎的进行每一次提交，不能再一股脑的把各种各样的改变都放在一个 git commit 外面，这样一来整个代码改变的历史也将更加清晰。
- 格式化的 commit message 才能够用于自动化输入 Change log。
监控服务
通常提出一个标准之后，为了大家更好的执行标准，就须要进行一系列的拉通，比方分享给大家这种标准的长处、能带来什么收益等，在大家都认同的状况下最好有一些强制性的措施。当然 git commit 标准也一样，后期咱们分享完标准之后思考从源头进行强制拦挡，只有大家提交代码的 commit message 不符合规范，间接不能提交。但因为代码仓库操作权限的问题，咱们最终抉择了应用 webhook 通过发送正告的模式进行监控，督促大家依照标准执行代码提交。除了监控 git commit message 的标准外，咱们还退出了大代码量提交监控和删除文件监控，缩小研发的代码误操作。
整体流程
- 服务注册：服务注册次要实现代码库相干信息的增加。
- 反复校验：避免 merge request 再走一遍验证流程。
- 音讯告警：对不符合规范以及大代码量提交、删除文件等操作发送告警音讯。
- DB：存我的项目信息和 git commit 信息便于后续统计 commit message 标准率。
webhook 是作用于代码库上的，用户提交 git commit，push 到仓库的时候就会触发 webhook，webhook 从用户的 commit 信息外面获取到 commit message，校验其是否满足 git commit 标准，如果不满足就发送告警音讯；如果满足标准，调用 gitlab API 获取提交的 diff 信息，验证提交代码量，验证是否有重命名文件和删除文件操作，如果存在以上操作还会发送告警音讯，最初把所有记录都入库保留。
以上就是咱们整个监控服务的相干内容，告警信息通过如下模式发送到对应的钉钉群里：
咱们也有整体 git commit 的统计，统计集体的提交次数、不标准次数、不标准率等如下图：
将来思考
git hooks 分为客户端 hook 和服务端 hook。客户端 hook 又分为 pre-commit、prepare-commit-msg、commit-msg、post-commit 等，次要用于管制客户端 git 的提交工作流。用户能够在我的项目根目录的.git 目录上面配置应用，也能够配置全局 git template 用于集体 pc 上的所有 git 我的项目应用。服务端 hook 又分为 pre-receive、post-receive、update，次要在服务端承受提交对象时进行调用。
以上这种采纳 webhook 的模式对 git commit 进行监控就是一种 server 端的 hook，相当于 post-receive。这种形式并不能阻止代码的提交，它只是通过告警的模式来束缚用户的行为，但最终不标准的 commit message 还是被提交到了服务器，不利于前面 change log 的生成。因为公司代码库权限问题，咱们目前只能增加这种 post-receive 类型的 webhook。如大家有更高的代码库权限，能够采纳 server 端 pre-receive 类型的 webhook，间接回绝不标准的 git commit message。只有 git commit 标准了，咱们甚至能够思考把代码和 bug、需要关联等等。
当然这块咱们也能够思考客户端的 pre-commit，pre-commit 在 git add 提交之后，而后执行 git commit 时执行，脚本执行没错就持续提交，反之就会驳回。客户端 git hooks 位于每个 git 我的项目下的暗藏文件.git 中的 hooks 文件夹里。咱们能够通过批改这块的配置文件增加咱们的规定校验，间接阻止不标准 message 的提交，也能够通过客户端 commit-msg 类型的 hook 进行拦挡，把不标准扼杀在萌芽之中。批改每个 git 我的项目上面.git 目录中的 hooks 文件大家必定感觉浪费时间，其实这里能够采纳配置全局 git template 来实现。然而这又会波及到 hooks 配置文件同步的问题。hooks 配置文件在本地，如何让 hooks 配置文件的批改能同步到所有应用的我的项目又成为一个问题。所以应用服务端 hook 还是客户端 hook 须要依据具体需要做适当的衡量。
git hook 不光能够用来做标准限度，它还能够做更多有意义的事件。一次 git commit 提交的信息量很大，有作者信息、代码库信息、commit 等信息。咱们的监控服务就依据作者信息做了 git commit 的统计，这样不仅能够用来监控 commit message 的规范性，也能够用来监控大家的工作状况。咱们也能够把 git commit 和相干的 bug 关联起来，咱们查看 bug 时就能够查看解决这个 bug 的代码批改，很有利于相干问题的追溯。当然咱们用同样的办法也能够把 git commit 和相干的需要关联起来，比方咱们定义一种格局 feat *786990（需要的 ID），而后在 git commit 的时候依照这种格局提交，webhook 就能够依据这种格局把需要和 git commit 进行关联，也能够用来追溯某个需要的代码量，当然这个例子不肯定适合，但足以证实 git hook 性能之弱小，能够给咱们的流程标准带来很大的便当。
总结
编码标准、流程标准在软件开发过程中是至关重要的，它能够使咱们在开发过程中少走很多弯路。Git commit 标准也是如此，的确也是很有必要的，简直不破费额定精力和工夫，但在之后查找问题的效率却很高。作为一名程序员，咱们更应重视代码和流程的规范性，永远不要在品质上将就。
