如何使用工具规范前端项目的commits与changelog技巧.docxVIP

第

如何使用工具规范前端项目的commits与changelog技巧

目录前言ConventionalCommits规范对于简短描述的扩充填写，可选哪些工具可以组合起来规范我们的commit？Commitizencz-customizablecommitlintstandard-version安装配置1.安装commitizen和cz-customizable2.安装commitlint3.安装standard-version总结

前言

项目的Changelog文件作为记录版本之间的差异和变更的主要公示板，主要用于传达一些关键的变更和指南，是直接与使用者对话的一种形式，所以changelog文件的整洁、直观一直是衡量一个项目质量的重要指标。

而且在我们翻阅一些组件库或者开源框架的changelog变动页的时候，经常看到一些项目的整齐、直观、井井有条如下面示例。这样的log日志必然不是手动排版出来的，大部分都是根据commit的描述自动生成的。

那么它们是如何配置，或者使用了什么工具包呢？想必大家都比较好奇。接下来我们就来一步一步揭开它神秘的面纱，并一步步的配置我们的组件库的commit规范，使我们的commit和changelog文件也能如此优雅。

示例一：semi的changelog文件

示例二：antd的githubchangelog

ConventionalCommits规范

要保持commit信息的可读性，一个合理的commit格式规范是必不可少的，而ConventionalCommits就是一种基于提交消息的轻量级约定。官方是这样描述它的：

它提供了一组用于创建清晰的提交历史的简单规则；这使得编写基于规范的自动化工具变得更容易。这个约定与SemVer相吻合，在提交信息中描述新特性、bug修复和破坏性变更。---ConventionalCommits官网

由此可以看出ConventionalCommits是一个非常友好且清晰的规范，那遵循它的好处有哪些？我们来进行一个总结：

可格式化信息，自动产生changelog；

校验拦截不符合规则的commit描述；

根据类型决定当前版本变更的性质；

统一提交信息，有利于代码审查者的阅读。

那么ConventionalCommits规则到底是如何的呢，我们接着往下看。通过官网的文档可以发现，它提交说明的结构如下所示：

类型[可选的作用域]:描述

[可选的正文]

[可选的脚注]

fix(docs):修复文档中字符错误

feat(components):tooltip组件初始化

可以看到，结构里面包含类型、作用域、描述、正文、脚注。

类型：用来标示当前提交是一个什么样的类型，比如最常见的有fix、feat等，用来标示当前的提交是一个修复类的操作，或者一个新功能的增加。可枚举的类型还有：chore、docs、style、refactor、perf、test等。这块可以参照@commitlint/config-conventional里面的枚举值。

作用域：此字段可自行定义枚举值，根据业务模块划分即可，比如：当前是【文档】的改动就可以填写docs；当前影响了utils库，就可以填写feat(utils)：等等，取值不限制。

描述：描述就是对当前commit的简短描述，尽量简短，清晰。

对于简短描述的扩充填写，可选

脚注：包含关于提交的元信息，比如：有关联的请求url、cr人员、等等一些关键性信息。

特别需要注意的是：在可选的正文或脚注的起始位置带有BREAKINGCHANGE:的提交，表示引入了破坏性API变更（这和语义化版本中的MAJOR相对应）。破坏性变更可以是任意类型提交的一部分。

可以看出ConventionalCommits规范非常高效且上手难度很低，并且ConventionalCommits已经被很多知名的开源项目所集成，是一个被大家广泛接受的标准。而我们的组件库也需要遵循它来规范我们的commit。

要如何遵循此规范呢？用插件来约束我们的commit是一个比较好的解决方案。接下来，我们来看下有哪些插件可以让我们愉快的使用。

哪些工具可以组合起来规范我们的commit？

Commitizen

上面我们说到了ConventionalCommits规范，我们要遵循此规范时，可能手动去处理commit信息会比较繁琐，并且