git commit 规范

提交代码时的commit内容不明确不完整。当回溯代码的时候，很难通过commit内容定位历史记录，只能一条一条查看，找不到就要去问历史参与开发的其他同事，沟通成本太高了。

为了提搞回溯的效率，方便定位问题，定义如下commit规范：

<type>: 【<scope>】<subject>

每个提交都必须使用类型字段前缀，它由一个名词组成，诸如 feat 或 fix ，其后接一个作用域字段，以及一个必要的冒号（英文半角）和空格。

type：提交类型；
scope：修改文件影响的范围，影响到全局，可以加个 global。如果影响的是某个目录或某个功能，可以加上该目录的路径，或者对应的功能名称（比如字体，layout布局，utils，router，工作台，市场，卡片编辑，组装卡片，PPT，管理后台，团队权限等）；
subject：用一句话清楚的描述这次提交做了什么，涉及到难发现/复现的bug（也可以加上描述为什么修改, 做了什么样的修改, 以及开发的思路等）；

commit type类型：

feat：新功能

fix：修补bug

docs：:文档修改

refactor：代码重构或性能优化（比如重构：既不是新增功能，也不是修改bug的代码变动；perf: 在不影响代码内部行为的前提下，对程序性能进行优化；style：代码格式修改，不影响代码运行的变动，不影响代码逻辑）

chore：其他杂项（比如构建过程或辅助工具；deps: 升级依赖；test: 测试用例新增、修改；build: 影响项目构建或依赖项修改；revert: 恢复上一次提交；ci: 持续集成相关文件修改；release: 发布新版本；workflow: 工作流相关文件修改）

比如：refactor: 【utils】新增相对路径转换方法relativePath2FullPath