共计 747 个字符，预计需要花费 2 分钟才能阅读完成。
提交代码时的 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
正文完
