commitmessage应该写的更清楚？在团队开发中遇到过让人头疼的gitcommit吗？本文分享了gitcommit规范构建的实践，规定了commitmessage的格式，提交时在Monitor中使用webhook，避免不规范的代码提交。后台Git每次提交代码都需要写commitmessage，否则不允许提交。一般来说，commitmessage应该清晰明了，说明这次commit的目的，具体做了哪些操作。。。但是在日常开发中，大家的commitmessage千奇百怪，中英文混用，fixbug之类的一般消息是家常便饭奇怪，这导致后续代码维护成本特别高，有时我都不知道我修复的bug修改的是什么问题。基于以上问题，我们希望通过一定的方式监控用户的gitcommit消息，让规范更好的为质量服务，提高大家的研发效率。规范建设前期，我们在网上搜索了很多关于gitcommit规范的资料，但是只有Angular规范是目前使用最广泛的一种书写方式，比较合理和系统，并且有配套的工具（IDEA有插件支持这种写法）。最后在阿里高德地图相关部门已有规范的基础上总结出一套gitcommit规范。Commitmessageformat():type(required)用于描述gitcommit的类别，只允许使用如下标识。feat：新功能（feature）。fix/to：修复bug，可以是QA发现的bug，也可以是R&D自己发现的bug。修复：生成差异并自动修复此问题。适合一次commit直接修复问题为：只生成diff，不自动修复问题。适合多次提交。使用fixdocs:documentation提交最终修复。style：格式（不影响代码执行的变化）。refactor：重构（即不是新特性，也不是改代码修改bug）。perf：与优化有关，比如提升性能和体验。测试：添加测试。杂事：对构建过程或辅助工具的更改。revert：回滚到之前的版本。合并：代码合并。sync：同步主线或分支上的bug。scope(optional)scope用于描述commit影响的范围，如数据层、控制层、视图层等，视项目而定。比如在Angular中，可以是location,browser,compile,compile,rootScope,ngHref,ngClick,ngView等，如果你的修改影响的范围不止一个，可以用*代替。subject（必填）subject是commit目的的简短描述，不超过50个字符。推荐使用中文（感觉中文能用中文更清楚的描述问题）。不要以句号或其他标点符号结尾。按照上面的规范，gitcommitmessage会有如下格式：fix(DAO):userquerylackstheusernameattributefeat(Controller):userqueryinterfacedevelopment以上就是我们整理的gitcommit规范，那么有哪些以这种方式标准化gitcommit的好处是什么？什么？方便程序员追溯提交历史，了解发生了什么。一旦commitmessage被constrained，就意味着我们会认真的进行每一次commit，不能再把各种变化都放在一个gitcommit中，这样整个代码的变化历史就会更加清晰。只有格式化的提交信息才能用于自动输出Changelog。监控服务通常在提出一个规范之后，为了让大家更好的去执行这个规范，需要进行一系列的拉通，比如分享这个规范的优点，可以带来什么好处。嗯，有一些强制措施。当然，gitcommit规范也是如此。我们前期分享规范后，考虑从源头强制拦截。只要你提交的代码的commitmessage不符合规范，就不能直接提交。但是由于代码仓库的操作权限问题，我们最终还是选择了使用webhooks进行监控，通过发送警告的方式，督促大家按照规范进行代码提交。除了监控gitcommitmessage的规范外，我们还增加了大量代码提交监控和删除文件监控，以减少研发中的代码误操作。整体流程服务注册：服务注册主要完成在代码库中添加相关信息。重复验证：防止合并请求再次经过验证过程。消息告警：对不符合规范的操作、提交大量代码、删除文件等发送告警消息。DB：存放项目信息和gitcommit信息，用于后续统计commitmessage规范率。Webhook作用于代码库。当用户提交gitcommit并推送到仓库时，webhook会被触发。webhook会从用户的commit信息中获取commitmessage，检查是否符合gitcommit规范，不符合则发送。报警信息；如果符合规范，调用gitlabAPI获取提交的diff信息，验证提交的代码量，验证是否有重命名文件和删除文件的操作，如果存在上述操作，则发送告警信息，最后所有记录将保存在数据库中。以上就是我们整个监控服务的相关内容。告警信息以如下形式发送到对应的钉钉群：我们也统计了整体的gitcommit，统计了单个提交的次数、违规次数、违规率，如下图：FutureThinkinggit钩子分为客户端钩子和服务器钩子。客户端钩子分为pre-commit、prepare-commit-msg、commit-msg、post-commit等，主要用于控制客户端git的提交工作流程。用户可以在项目根目录的.git目录下配置使用，也可以在个人pc上为所有的git项目配置一个全局的git模板。服务器端钩子分为pre-receive、post-receive和update，主要在服务器接受提交的对象时调用。上面以webhook的形式监控gitcommit是一个server端的hook，相当于post-receive。此方法不会阻止提交代码。只是以告警的形式约束了用户的行为，但最终还是将不规则的commitmessage提交给了服务器，不利于后续生成changelog。由于公司代码库的许可，我们目前只能添加这种post-receivewebhook。如果你有更高的代码库权限，你可以使用服务器端预接收类型的webhook直接拒绝不规则的gitcommit消息。只要gitcommit规范化，我们甚至可以考虑将代码与bug、需求等相关联。当然我们也可以考虑client的pre-commit。pre-commit在gitadd提交后执行，然后在执行gitcommit时执行。如果脚本执行正确，则继续提交，否则将被拒绝。客户端githooks位于每个git项目下的隐藏文件.git中的hooks文件夹中。我们可以通过修改这个配置文件，加上我们的规则校验，直接阻止不规则消息的提交，也可以通过clientcommit-msg类型的hook拦截不规则消息，将不规则行为扼杀在萌芽状态。修改每个git项目下.git目录下的hooks文件肯定很浪费时间。其实这可以通过配置全局的git模板来完成。但是这会涉及到hooks配置文件的同步。hooks配置文件是本地的，那么如何将hooks配置文件的修改同步到所有使用的项目就成了另一个问题。因此，是使用服务端钩子还是客户端钩子，需要根据具体需要适当权衡。Githooks不仅可以用来限制规范，还可以做更有意义的事情。一个gitcommit会提交大量的信息，包括作者信息、代码库信息、commit等信息。我们的监控服务根据作者信息对gitcommit进行统计，不仅可以用来监控commit信息的规范性，还可以用来监控大家的工作情况。我们还可以将gitcommit与相关的bug联系起来。我们在检查bug的时候，可以检查代码修改来解决bug，这对于相关问题的溯源是很有帮助的。当然，我们也可以用同样的方法将gitcommit和相关需求关联起来。比如我们定义一个格式feat*786990（requirementID），然后gitcommit的时候按照这个格式提交，webhook就可以根据这个格式将requirements和gitcommit关联起来，也可以用来追踪提交的数量特定要求的代码。当然这个例子可能不太合适，但是足以证明githook的强大，可以给我们的流程规范带来很大的方便。综上所述，编码标准和流程规范在软件开发过程中至关重要，可以让我们在开发过程中少走很多弯路。Gitcommit规范也是如此，确实是必须的，几乎不需要额外的努力和时间，但是后期发现问题的效率很高。作为程序员，更应该注重代码和流程的标准化，绝不在质量上妥协。
