简介： 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标准也是如此，的确也是很有必要的，简直不破费额定精力和工夫，但在之后查找问题的效率却很高。作为一名程序员，咱们更应重视代码和流程的规范性，永远不要在品质上将就。