前言

上篇中主要介绍了Vue3中Readme的相关内容。看完Readme文档,对Vue3的功能及特性有了解后可以开始准备有的放矢的深入源码了。查看源码的第一步，一个比较好的方式是先概览Git Log，对整个开发周期中的提交流程开发流程有一个粗略的了解。在看Vue3的Log的过程中发现其规范和校验方式对于平时的业务开发大有裨益，故此本篇分享一下log规范相关的内容。

内容

打开git可视化工具(mac推荐soureTree ，window推荐tortoisegit)查看，下图是vue3的部分注释截图，可以清楚的看的有较标准的格式规范。可以通过类型 (feat|fix|docs|dx|style|refactor|perf|test|workflow|build|ci|chore|types|wip)及内容清晰的区分出提交的内容作用等。

vue3的规范除了约定之外 , ./script/verifyCommit.js中还有专门的格式强制校验，在gitHook commit-msg的钩子里执行校验。提交msg自动校验规范】，不符合规范的commit不允提交。

那么为什么要有提交规范呢，使用Git Log规范一般有3个目的

自动生成 CHANGELOG.md
识别不重要的提交
为浏览提交历史时提供更好的信息

如何定制一套自己的规范
这里给出是一套可供参考的注释规范 引用参考:

    <type>(<scope>): <subject>
    <BLANK LINE>
    <body>
    <BLANK LINE>
    <footer>

subject 是对变更的简要描述。
body 是更为详细的描述。
用于说明 commit 影响的范围

type 则定义了此次变更的类型，可根据业务适当增减

fix：问题修复
docs：文档变更
style：代码风格变更（不影响功能）
refactor：既不是新功能也不是问题修复的代码变更
perf：改善性能
test：增加测试
chore：开发工具（构建，脚手架工具等）
footer 可以包含 Breaking Changes 和 Closes 信息。

总结

到这里大家可以回想一下平时业务开发时是否有制定相关的注释规范，是约定式的还是强制式的。如果没有，且在排查问题查时已经出现无法通过Log区分出提交的目的和内容了，那么就可以在最近迭代的中抓紧制定适合自己项目的注释规范了。方式的话，建议先约定，视约定的执行效果确定是否加入强校验。如果是前端项目尤神的校验代码可以拿过去简单修改直接使用。如果是其他类型的项目，可以稍微搜索调研一下，应该成本不高。

搜获关键词

git log规范 githook changlog

发散问题

如果是java或者go等其他语言的项目，一般通过什么样的方式做git log的格式校验，是否有通用的校验方式

以上问题，平时在工作中有了解或者有最佳实践的同学也可以不吝分享一起探讨提高

看vue3源码可以学到什么 : 二、Git Log规范

前言

内容

总结

搜获关键词

发散问题