规范-适当的规范

废话文学

最近看了一些提交规范的文档，想起来在上家公司的时候，是有用到cz来进行提交规范，但是当时并没有细研究这个玩意。今天来板板废话文学文章的毛病，采用SCQA工具来进行本篇文章的输出。

（S）日常开发

一个项目往往都不是只有一个FE来进行维护的，通常是多个FE来进行维护。通常我们的流程都是本地开发自测，提交代码，提测。时间久了，越来越多的提交，这时候我们打开历史的commit，oh，no！

可以知道改动了，可以知道提交代码了，但是改动了什么呢？本次改动影响大不大呢？等等，带着一系列的问题。这个时候，会不会特别的头大。

（C）对比

贴张图来对比下：

在日常开发需求迭代如此快的基础上，如果我们没有任何额外的说明，大家按照自己的工作方式只是把内容提交上去，日积月累，大家可以想象到会堆成什么样子。相反，如果我们按照规范来进行提交，这样每次做了哪些修改，修改了哪些文件，这次修改主要是哪方面的修改等等，是不是一目了然呢。

（Q）都有啥呢

ok，通过上面一系列的举例，我们已经可以很清楚的知道这个规范对于我们的重要性了吧，那我们应该如何在项目里规范这个东西呢？
经过在知识海洋里不断的畅游，我发现commitizen + husky + commitlint这三个应该是非常符合俺们的。

（A）commitizen

Commitizen是一个撰写合格 Commit message 的工具。

正常我们提交之后需要git commit -m嘛，既然安装了这个好东西，我们直接git cz就可以了。这时，就会出现选项，用来生成符合格式的 Commit message。
1、可参考规范如下：

• build：主要目的是修改项目构建系统(例如 glup，webpack，rollup 的配置等)的提交
• ci：主要目的是修改项目继续集成流程(例如 Travis，Jenkins，GitLab CI，Circle等)的提交
• docs：文档更新
• feat：新增功能
• merge：分支合并 Merge branch ? of ?
• fix：bug 修复
• perf：性能, 体验优化
• refactor：重构代码(既没有新增功能，也没有修复 bug)
• style：不影响程序逻辑的代码修改(修改空白字符，格式缩进，补全缺失的分号等，没有改变代码逻辑)
• test：新增测试用例或是更新现有测试
• revert：回滚某个更早之前的提交
• chore：不属于以上类型的其他类型

2、输入本次改动的文件

3、简短描述下这个改动

4、详细描述下这个改动

5、是否有破坏性改动

6、这个改动是不是影响了打开的issues

7、最后就可以看到我们的改动了

（A）husky

首先仓库奉上：https://github.com/typicode/husky

简介

让我们来看看这个husky是个什么东东呢？

husky改善你的commits和更多的
？？哈哈哈，属实有点搞笑了哦～
Husky 能够帮你阻挡住不好的代码提交和推送。一句话很精准的说明了这个库的意义，而配置也非常简单。

就像这样，在我们的 package.json 中配置 husky，并且在对应的 git hook 阶段来执行对应的命令。于是乎，不用繁琐的去配置 git hook 阶段的脚本文件了，提供对应的 node 操作变好。

（A）commitlint

在有了Husky赋能之后，我们有能力在Git的钩子里做一些事情，首先不得不提的是代码的提交规范和规范的校验，优雅的提交，方便团队协作和快速定位问题。首推Commitlint。

npm install --save-dev @commitlint/config-conventional @commitlint/cli

// 生成配置文件commitlint.config.js，当然也可以是 .commitlintrc.js
echo "module.exports = {extends: ['@commitlint/config-conventional']};" > commitlint.config.js

"husky": {
    "hooks": {
      "pre-commit": "npm run test",
      "commit-msg": "commitlint -e $HUSKY_GIT_PARAMS"
    }
  },

验证下不符合规范提交时

俺参考的文档

不搞过多废话文学，先来贴自己参考的文档
1、阮一峰Commit message 和 Change log 编写指南
2、commitizen + husky + commitlint规范实践

总结

总之，这个东西就是一个类似于约束类的东西吧，我觉得美观也蛮重要的，毕竟我们的代码，我们的commit都是给我们自己看的，真正使用你呈现出来产品的人是看不到这些东西的。总不至于，今天代码写完，过了一阵，自己看今天的代码，发现完全看不懂了，这个时候我们是不是要反思下我们呢～