前言

在项目的协作开发中，有一个统一的编码规范，对于各个前端coder而言，我认为是极好的，至少在代码的阅读和维护方面，接手的成本会低一些。除此编码的规范外，代码的提交规范，对于后期接手的人而言，也是行方便之处，至少能看得懂吧，哈哈哈。

本文，是代码提交规范的学习笔记。

规范介绍

相信绝大部分应该都是使用git做代码管理的，市面上认可度很高，成熟度很高的规范是Angular提交规范，公认为最合理、最系统、最流行。

格式

Angular的提交格式包括：Header，Body，Footer三个内容，Header为必填项，后面两个是选填的。

<type>(<scope>): <subject> 
# 空一行 
<body>
# 空一行 
<footer>

Header

该部分仅书写一行，包括三个字段，分别是type、scope和subject。

type：用于说明commit的提交类型，必选
scope：用于说明commit的影响范围，可选
subject：用于说明commit的细节描述，可选

常用的type类型：

类型	功能	描述
feat	功能	新增功能，迭代项目需求
fix	修复	修复缺陷，修复上一版本存在问题
docs	文档	更新文档，仅修改文档不修改代码
style	样式	变动格式，不影响代码逻辑
refactor	重构	重构代码，非新增功能也非修复缺陷
perf	性能	优化性能，提高代码执行性能
test	测试	新增测试，追加测试用例验证代码
build	构建	更新构建，改动构建工具或外部依赖
ci	脚本	更新脚本，改动CI或执行脚本配置
chore	事务	变动事务，改动其他不影响代码的事务
revert	回滚	回滚版本，撤销某次代码提交
merge	合并	合并分支，合并分支代码到其他分支
sync	同步	同步分支，同步分支代码到其他分支
impr	改进	改进功能，升级当前功能模块

scope：用于描述commit的影响范围，按功能分，如数据层，视图层，控制层等；按交互分的话，如组件，布局，流程，视图，页面等，建议补全（实际上目前我没见过写这个，毕竟，没去过大厂）。

subject：用于描述commit的细节，一般用精简的语句描述修改点（详细的描述一般是放在Body里面的）

// 例子：
feat(View): 新增主题皮肤切换按钮 
feat(View): new the button for theme skin switching

Body

个人理解算是对subject的详细描述，可以写多行，内容应该包括修改动机，以及修改前后对比

Footer

两种情况：

不兼容变动：意思是当前的改动之后，和上一版代码不兼容，以BREAKING CHANGE开头，关联变动描述、变动理由、迁移方法
问题关闭：当前代码已经修复某些ISSUE，以Close开头，关联目标Issue

部署

使用到了插件commitizen，cz-conventional-changelog，commitlint

commitizen

基于模板驱动的约束规范工具，可扩展性很强

使用commitizen的git cz命令可代替git原生的git commit命令，帮助开发者生成符合规范的git提交说明。指定一个符合Angular提交规范的书写配置：cz-conventional-changelog，是的commitizen根据指定规范帮助开发者生成提交说明。

全局配置

npm i -g commitizen cz-conventional-changelog

Windows系统：在C:/Users/$USER目录中创建.czrc文件
MacOS系统：在~目录中创建.czrc文件

{ "path": "cz-conventional-changelog" }

根据不同情况，使用cz-customizable插件来自定义规范

npm i -g cz-customizable

{ "path": "cz-customizable" }

局部部署

npm i -D commitizen cz-conventional-changelog

// package.josn
{ 
    "script": { 
        "commit": "git-cz" 
     }, 
     "config": { 
         "commitizen": { 
             "path": "node_modules/cz-conventional-changelog" 
         }
     }
 }

根据不同情况，使用cz-customizable插件来自定义规范

npm i -D cz-customizable

// package.josn
{ 
    ...
    "config": { 
        "commitizen": { 
            "path": "node_modules/cz-customizable" 
        }
    }
}

创建.cz-config.js来自定义规范

在Windows系统全局部署：在C:/Users/$USER目录中创建.cz-config.js文件
在MacOS系统中全局部署：再~目录中创建.cz-config.js文件
在项目中局部部署：在根目录中创建.cz-config.js文件

commitlint

除了提交说明，使用commitlint来校验提交说明，有时候也是很重要和需要的。commitlint的校验标准很严，不符合的统统不通过。

安装

npm i -D @commitlint/cli @commitlint/config-conventional

在根目录中创建.commitlintrc.js

module.exports = { 
    extends: [ "@commitlint/config-conventional" ],
    rules: {} 
};

同时，也可以通过commitlint-config-cz来自定义规范，用于某些特殊情况。

npm i -D commitlint-config-cz

在.commitlintrc.js文件中，重新指定extends和rules即可

后话

编码规范也好，提交规范也好，甚至是命名规则，这些都是为了在协作开发中能更好的统一，方便不同开发之间的团队协作，以及后面开发者接手和交接。更重要的是，方便阅读和维护

参考资料

掘金小册：从0到1落地前端工程化

前端工程化之提交规范

前言