我的同事们都在努力认真的工作，不放过一分一秒。可是突然到来的会议邀请打断了我们的专注。

git 提交规范

我们都放下了手中做不完的工作，参加了这个具有“划时代”意义的会议。

领导从电脑面前抬起头，环视了一下四周，看到人都到齐了，他把电脑往前推了推，凳子向后摞了摞，然后讲到。

领导： 先说明一下为啥要开这个会，我发现大家提交代码的格式不规范，不利于将来找原因。

同事们都很安静，个别同事低了低头。领导停顿了一下，发现大家都没有说话，于是继续讲到。

领导： 我整理了一份提交规范，大家看看。

领导打开了规范文档。

提交类型(范围?): 主题 #范围是可选的; 支持多个范围（当前分隔符选项："/"、"" 和 ","）

类型有以下这些：

举例：

feat: 完成对 A 功能的开发fix(login): 登录可以多次点击

同事 A 看了看规范文档，思索了一下，不解的问到。

同事 A ： 如果是为了将来看当下的变更，我觉得只要我们把提交内容写清楚不就可以了嘛？

领导微笑的讲到。

领导： 我们想看看某个版本的更改，如果按照你说的方式，我们怎么得到呢？

同事 A ： 查看每一次提交，然后汇总每一次提交的内容，比如：

假设提交内容：

整理后的版本记录：

新增：
  1. 超级会员的功能
修复：
  1. 进入详情页返回没有效果

领导： 那这样的效率是不是很低呢，如果我们规范化，这些记录完全可以使用脚本生成，解放双手。

同事 B 立马想到，即便是规范的信息生成记录，那本身编写这个脚本也是需要时间的，虽然是一本万利的事情，但是同事 A 说的方式其实也可以规范一下内容，然后在此基础上编写脚本也是一样的效果。然后同事 B 讲到。

同事 B ： 领导，我觉得同事 A 说的方式规范一下内容也能达到这样的效果，比如：

基于上面的假设的内容更改：

同事 A ： 对呀，这样还都采用汉字岂不美哉。

领导： 那这套规范谁来定呢？

同事 A ： 我可以定。

领导： 非常好，只不过我还想问一个问题，这类规范是不是我们第一次用？

大家： 对

领导： 刚开始的时候怎样是最不容易出错的？

同事 A ： 规范应该不会出现错误吧。

同事 C 联想到自己第一次开发蓝牙功能时，自己做传输数据的规范，因为考虑不周导致后面改动比较多，于是对同事 A 讲到。

同事 C ： 这个可不一定，有些东西你没弄过，就可能考虑不周到，导致会经常修改。

领导： 对，就是这样，我们第一次接触的时候很多都没遇到过所以就存在考虑不周。

同事 A ： 可领导你定的这套规范难道不是你弄的嘛？

领导： 当然不是，这是目前市面上很受欢迎的规范。

说着的时候领导打开了规范的网站： 。然后给大家介绍其内容。

领导： 可以看到格式也非常的简单，只需要这样：

[optional scope]:

[optional body]

[optional footer(s)]

其中除了 type 是约定的以外，其余的都是根据实际内容来编写，例如：

feat(auth): add support for OAuth login
Added OAuth login integration to allow users to sign in with Google and Facebook.

这是新增功能的提交示例，其中在这个例子中：

fix(login): prevent multiple form submissions
Fixed an issue where users could submit the login form multiple times by clicking the button repeatedly.

这是修复 bug 的提交示例。

同事 B 看到这个觉得很不错，但是他转念一想，这个规范虽然好，但由于刚开始执行，还没养成习惯就很容易出现忘记的情况，如果忘记了怎么办，于是他问到：

同事 B ： 可是领导要是我不小心忘记了怎么办？

领导：如果你最近一次忘记按规范提交了，可以使用：

git commit --amend

来重新修改，比如最近一次提交没有按照规范：

当你执行完 git commit --amend 后：

修改完成后 Esc 然后输入 wq 回车就修改成功了。

同事 B ： 如果我多次都忘记了怎么办？

领导： 很简单，使用：

git rebase -i HEAD~N

假如你忘记按规范提交的记录是这样的：

输入 git rebase -i HEAD~2 后：

然后：

然后就会出现下面交互：

此时出现的是 简单+-*/ 这次提交的修改，如果你需要修改就在终端输入 git commit --amend ，然后进入的界面就跟上面的相同；只不过当你 wq 保存退出后会出现：

此时代表第一个的修改已经完成了，此时就需要输入 git rebase --continue ，进入到第二次的交互界面，也跟上面相同，然后继续之前相同的操作，等全部完成后，就会出现：

此时你再看提交记录就发生改变了：

同事 B 点了点头。同事 A 看到这么多就觉得有点头大，心中有点不开心，但还是平静的讲到。

同事 A ：这样似乎有点麻烦呀！

领导感受到了同事 A 的不满意，领导心里却非常的高兴，因为此时他想到了“懒惰造就更高效的工作”。于是就想到用启发式的方式问到。

领导： 既然你觉得麻烦，你有啥好办法呢？

同事 A ： 想想，如果有一个脚本啥的，在提交的时候就检查，如果不规范就不让提交。

同事 C 想到他之前在基于CodePush的多功能分支管理中用到了 git 钩子 ， 这个钩子就能完美的完成这个任务，只需要在这个钩子中检查 commit 的文案是否符合规范。

同事 C ： 利用 这个 git 钩子 就能在 commit 的时候检查是否符合规范。

提交阶段钩子

推送阶段钩子

服务器端钩子

同事 A ： 调用时机找到了，现在还剩下验证是否符合规范的脚本，等我有时间了写一个给大家用。

领导发现大家积极发言谈论问题，思考解决方案，变得高兴起来。

领导： 很好，只不过现在你们都非常忙，如果非要编写，就只能加班来编写了。可是我们公司是不让加班的。

领导顿了顿。同事 D 心里面泛起了嘀咕，明面上不让加班，可是为了完成工作，最后我们还是加班了，只是没在公司而已。同事 A 心里说到，我可以回去写这个脚本，但是他又怕同事们觉得他很卷，只是在心里讲了讲，终究是没开口。

领导： 我在调研这个时候已经都弄好了，不需要我们来编写这个脚本，现在有现成的给大家使用。

同事 D 在心里说到果然我们公司都是很喜欢使用成熟方案的。同事 C 突然想到之前逛 github 看到的一个工具，但是想不起名字，就盯着一个地方思考。

同事 C ：是不是 commitlint 呀？

领导： 是的。

同事 E 用鄙夷的眼光偷看了同事 C ，默念到，就你能，咋不上天，最不喜欢这种喜欢在领导面前卖弄的人。

领导： 同事 C 你来给大家讲讲这个怎么使用。

同事 C 立马呼吸加快了起来，头低了下来，把手放到口袋里，但是却没有放进去，又放了两次还是失败了，最后把手放到了桌子上，抬起头看了看领导。

同事 C ： 我只是了解过，我，我也没用过。

领导看出了同事 C 的紧张，心里面想着，看来他需要多锻炼。

领导： 没关系，等两天再讲，这个会开的时间已经够长了。好，今天这个会就开到这里，这两天大家先按规范编写，等两天后我们再开会看看大家写的，同时让同事 C 到时候跟大家讲讲 commitlint 的使用。

领导意犹未尽的继续说到。

领导： 我知道大家都很忙，现在还弄这些耽误大家时间的东西，有点说不过去；但是呢这个问题又出现很久了，短期内大家都会很忙，不可能推到以后再弄。其实你们想想，我们发版这么频繁，每次你们编写更新日志的时候也是需要花费不少时间的。如果我们规范化了到时候这些就不费什么时间了。

大家散会后，又开始忙碌起来了。大部分人转眼就忘了，提交的信息仍然比较随意，其中上次开会的同事 C 由于领导要求要跟大家讲所以记录都写得不错。在这个过程中还发生一件事情，也就是线上出现了 bug ，需要去追溯什么时候引入的问题，但由于提交记录不规范，导致基本上是靠记忆和翻阅代码才找到的，而且找了很久；因为这个事情同事 E 和同事 A 吵了一架，因为同事 E 觉得只要解决了问题就可以了，而同事 A 非要看怎么导致的问题，同事 A 的想法很简单，觉得真正的排查问题是知根知底，而不是简单的排查，这样才不至于出现改出新问题。

两天的时间很快就到了，领导又发起了会议，大家也都陆陆续续停下了手中的工作去参加了会议。

领导打开了一个 markdown 的文档，上面是一条条提交，一看就知道是 git 的提交记录，只不过通过记录看不出是谁写的，领导故意没有截提交人的名字。

增加了忘记密码的功能

修复了验证码倒计时的问题

增加了大量的功能

优化了一些体验

格式化代码

feat(login): 微信登陆

fix(user): 退出登陆点击无效

修复一些问题

...

领导：这是这两天大家提交的记录，其中有值得表扬的，也有值得批评的。其中同事 C 写得很不错。我发现大部分都没有按规范写。

同事 B ： 要不是开会我都想不起这事。

大部分同事附和到。

领导：没事，毕竟刚开始弄，不习惯忘记啥的都很正常。只不过我还是要批评个别人写的提交记录，比如修复一些问题这种提交信息一点营养价值都没有。我就不点名了，希望大家提交记录的时候都认真一些。这两天你们也再次遇到了需要查看之前记录的问题，正好用上。

同事 E 轻哼了一下。

领导： 经过这两天的实践，我们主要有以下问题：

提交的内容太含糊其辞；没有按照规范来编写。

其中第一个需要大家严格执行；至于第二个我们使用工具就可以解决。接下来就让同事 C 来给我们讲讲怎么使用 commitlint 。

领导把电视的转接头递给了同事 C，同事 C 连上后就讲到。

同事 C ： 使用 commitlint 非常简单，我现场操作给大家看一下。

同事使用 vscode 打开了一个示例的项目。

安装 commitlint 相关的包（版本： "@commitlint/cli": "^19.6.1" ， "@commitlint/config-conventional": "^19.6.0" ）：

npm install --save-dev @commitlint/{cli,config-conventional}

生成配置文件：

echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.mjs

安装 husky （管理 git hooks ，安装的版本 "husky": "^9.1.7" ）：

npm install --save-dev husky

初始化 husky ：

npx husky init

将 commitlint 的校验放到脚本中：

# Add commit message linting to commit-msg hook
echo "npx --no -- commitlint --edit $1" > .husky/commit-msg
# Windows users should use ` to escape dollar signs
echo "npx --no commitlint --edit `$1" > .husky/commit-msg

启用 husky ：

npx husky install

接下来就可以尝试了提交了。先编写一个不对的：

点击提交就会出现下面的错误：

如果改成正确的，如 git commit -m "chore: 删除默认pre-commit"就能正常提交了。

同事 C ： 到目前为止已经结束了。/guides/gett… 这是官网的地址，更多详情去这里面看。

领导鼓掌，然后大家一起鼓掌。

同事 A ： 这个就非常的 nice 。

领导： 讲得非常好。会后大家在项目中都安装上，这样就不会出现不按照规范提交的了。同时之前你们反馈过，说每次发版本还需要手动写版本记录很麻烦，等你们都按照规范写以后，我们就可以使用一个工具自动生成记录了。

安装生成 CHANGELOG.md 的工具：

npm install -g conventional-changelog-cli

然后在 package.json 中增加 version 的 script ：

{
    "scripts": {
        "version": "conventional-changelog -p angular -i CHANGELOG.md -s && git add CHANGELOG.md"
    }
}

这样当更新版本的时候只需要执行 npm version [patch|minor|major]就能自动生成了。生成效果如下：

领导： 你们觉得怎么样？

大家都不同程度的点了点头。

领导： 好，那就先这样定了，你们在实践的过程中看看还有什么问题，我们继续思考改进。