团队管理之 git 提交规范：commit 记录那点事儿

前言

之前有同事总是喜欢格式化代码后提交，凡是他更改过的文件，哪怕只有 1 行，整个文件也会被他格式化。回头再看 git 提交记录，好家伙，历史 commit 全被覆盖了~

再看看之前某个小项目的 git 提交记录：

小老弟，这满屏的 1 是怎么回事？

看到这里，你可能以为这是小公司不规范的提交记录，实际上这并不是仅仅是小公司的问题。如果团队负责人没有做好规范，同事水平良莠不齐，不管大公司还是小公司，都会有这样的问题。从这点来看，团队中 git 提交规范是很有必要的，那么 git 提交都应该注意哪些问题呢？今天，大冰块就来好好理一下 git 提交那点事儿~

commit 三要素

主流的提交规范一般包括：标题（类型、精简总结）、内容、备注 。其中精简总结 是必填的，类型 最好也填一下，其余都是选填。

下面大冰块来见到那介绍一下这三个方面具体都指的是什么：

一、标题

标题分为 类型 、 改动范围 、 精简总结 三部分：

1、类型

规范的主要类型如下：

• feat：新功能或功能变更相关

• fix：修复 bug 相关

• docs：改动了文档，注释相关

• style：修改了代码格式化相关，如删除空格、改变缩进、单双引号切换、增删分号等，并不会影响代码逻辑

• refactor：重构代码，代码结构的调整相关（理论上不影响现有功能）

• perf：性能改动，性能、页面等优化相关

• test：增加或更改测试用例，单元测试相关

• build： 影响编译的更改相关，比如打包路径更改、npm 过程更改等

• ci：持续集成方面的更改。现在有些 build 系统喜欢把 ci 功能使用 yml 描述。如有这种更改，建议使用 ci

• chore：其它改动相关，比如文件的删除、构建流程修改、依赖库工具更新增加等

• revert：回滚版本相关

其实实际开发中最常用的就是 feat、fix 和 perf，git 提交基本上都是实现需求，更改 bug，性能优化。除了上述这些主要类型，我们也可以根据团队要求定制类型，毕竟规范是死的，人是活的嘛。比如为了大家更易读，我们只留几个常用的，并且全改成中文，如：

• 功能更改：新功能或功能变更相关

• 修复 bug：修复 bug 相关

• 优化：性能改动，性能、页面等优化相关

没有好与不好之分，适合团队的就是最好的！

2、改动范围

当项目划分为好几个模块的时候，指定改动的模块是很有必要的事情，这样在 git 提交记录中，很容易看出提交者更改的是哪个模块。比如本次修改了 compiler（编译器）模块，下次修改了 router（路由）模块，一目了然。如：

• compiler

• router

3、精简总结

必填的精简总结是非常重要的，一般是是总结概括的文字。要让人一眼就能看出来主要提交了什么，是添加了功能还是解决了问题，同时它也是大多数 git 管理工具默认展示的一行。如果你写的标准，那么提交记录看起来就很漂亮很规整。例如：

  fix: 修复了无限抽奖的bug

二、内容

内容主要填写详细的改动内容，可换行。当然，不必像写一篇小作文似的长篇大论，毕竟我们程序员的时间还是很宝贵的。如果精简总结写的比较完美，内容不写也是没关系的。不过如果更改确实很多，并且时间充裕的话，把本次提交内容的实现、需求以及背景都填写，是很负责的做法。比如：

  fix: 修复了无限抽奖的bug
  在网络不好时，多次抽奖的接口可以被重复调用。  此次更改了抽奖接口的逻辑判定，在并发请求中……采用了……所以……。

三、备注

备注看起来并不是那么重要，主要作用就是有一些额外的 hook 补充，比如提交记录之后，自动触发代码联动编译，或者自动生成 git 提交的通知。

后记

规范了团队的 git 提交，commit log 记录一目了然，配合自动化集成工具即可自动生成 git change log。以及调用邮箱接口提示，自动发送提交、构建、发版的人员记录，所以团队管理的 git 的提交规范是很有必要的，甚至是不可或缺的一部分。

本文旨在提供 git 规范化提交的思路，提前发现问题，解决问题，不至于在翻看 git 记录时一脸懵。如果对你有帮助，点个赞就好，如果有错误欢迎指出交流。感谢阅读~