Git代码提交规范

在开发过程中，每次提交代码都写git commit meesage提交说明，但由于提交的说明并没有规范，导致每个人提交的说明都不统一，甚至常常几个文字敷衍了事并不能反映此次提交的代码做了什么，日后自己查看提交记录回顾却什么也记不起来，所以对于此种情况，我们需要用到一些工具来约束我们的git提交。

我们常常在逛github会发现大部分仓库的提交日志格式很统一，并且仓库会附带CHANGELOG.md来记录变更日志，就像如下图所示：

那这种提交规范是怎样做到的呢？其实目前这种提交规范是遵循的Angular 规范 约定式提交，这是目前使用最广的写法，比较合理和系统化，并且有配套的工具。

规范格式

规范中规定了提交格式：

<类型>[可选 范围]: <描述>
[可选 正文]
[可选 脚注]
===================================
其中的
<类型>可以是如下几种，也可以根据项目情况去添加
feat：类型 为 feat 的提交表示在代码库中新增了一个功能
fix：类型 为 fix 的提交表示在代码库中修复了一个 bug
build: 用于修改项目构建系统，例如修改依赖库、外部接口或者升级 Node 版本等；
chore: 用于对非业务性代码进行修改，例如修改构建流程或者工具配置等；
ci: 用于修改持续集成流程，例如修改 Travis、Jenkins 等工作流配置；
docs: 用于修改文档，例如修改 README 文件、API 文档等；
style: 用于修改代码的样式，例如调整缩进、空格、空行等；
refactor: 用于重构代码，例如修改代码结构、变量名、函数名等但不修改功能逻辑；
perf: 用于优化性能，例如提升代码的性能、减少内存占用等；
test: 用于修改测试用例，例如添加、删除、修改代码的测试用例等。
=======
[可选 范围]是可选的，比如当前提交的模块或者组件等一个非常简短的范围描述
=======
<描述>则表示对当前提交的描述，比如添加了什么功能，修复了什么功能
=======
[可选 正文]表示非常详细的描述也是可选的可以多行输入，比如此次修改变更了那些文件和代码，是否有破坏性更新，受影响的代码有哪些
=======
[可选 脚注]表示一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接，比如修复关闭了那些issues等
===================================

参照上面的格式，提交的时候提交信息就可以这样写：
比如新增了用户管理模块：
feat(userManagement): 新增了用户管理模块
api接口下添加了user文件夹作为用户管理模块相关的api接口
icon下新增了相关图标，修改了全局的icon配置

再比如修复功能：
fix(video): 修复video关闭时没有及时卸载导致逐渐卡顿的bug

以上就是git提交的规范格式，但对这种提交格式来说，手写会很麻烦而且容易写错，所以需要一些插件来辅助我们规避掉手写所带来的不便。

命令行工具

常见的命令行工具有很多种，需要搭配使用比如：

commitizen+@commitlint/config-conventional

commitizen+cz-customizable

commitizen+cz-git

推荐使用commitizen+cz-git的方式

安装

npm install -g cz-git commitizen

然后需要在系统用户目录下建立.czrc文件来生效git cz命令插件

windows系统在C:/Users/xxx(用户名)/.czrc

Macos或者Linux系统在~/.czrc

编辑 ~/.czrc 文件以 JSON 格式添加配置:

{
  "path": "cz-git"
}

通过全局安装后，命令行工具可以代替git commit命令，改用git cz来提交说明，它通过询问式的交互来一步步的生成规范的格式

当代码有变更需要提交时，按照git提交代码的流程需要先执行git add来提交代码到暂存库，然后再执行git commit来提交到本地仓库，这时git commit命令就可以用git cz来代替进行规范格式提交：

git cz
== 1 ========================
第一步会询问你<类型>是什么？
? Select the type of change that you're committing: Use arrow keys or type to search
❯ feat:     A new feature 
  fix:      A bug fix 
  docs:     Documentation only changes 
  style:    Changes that do not affect the meaning of the code 
  refactor: A code change that neither fixes a bug nor adds a feature 
  perf:     A code change that improves performance 
  test:     Adding missing tests or correcting existing tests 
(Move up and down to reveal more choices)
== 2 ========================
第二步会询问你[范围](可选)是什么？如果不写则选择empty选项
? Denote the SCOPE of this change (optional): Use arrow keys or type to search
❯ empty 
  custom 
== 3 ========================
第三步会询问你<描述>是什么？需要填写简短的描述
? Write a SHORT, IMPERATIVE tense description of the change:
 [Infinity more chars allowed]
== 4 ========================
第四步会询问你<正文>(可选)是什么？需要填写更详细的描述，通过“|”来换行
? Provide a LONGER description of the change (optional). Use "|" to break new line:
== 5 ========================
第五步会破坏性更新有哪些(可选)使用“|”换行
? List any BREAKING CHANGES (optional). Use "|" to break new line:
== 6 ========================
最后一步会询问你要关联关闭哪些ISSUES(可选)
? Select the ISSUES type of change (optional):
=============================
最后会生成符合规范的提交信息，会询问你是否确认提交，选择是的话，最终会附带生成好的信息执行git commit

后续如果想推送到远程仓库就可以执行git push命令来推送本次提交了

CHANGELOG.md

当有了统一的git提交规范后，下一步就可以通过提交的记录生成变更日志CHANGELOG.md了。

常见的工具有：

conventional-changelog-cli

standard-version

以conventional-changelog-cli为例

安装

npm install conventional-changelog-cli --save-dev

安装完成后，在package.json中加入配置方便使用

{
  "scripts": {
  + "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s"
  }
}

最后通过执行命令，在项目目录下生成 CHANGELOG.md 文件

npm run changelog