阅读 1421

团队管理之git提交规范:大家竟然都不会写commit记录?| 周末学习

这是我参与更文挑战的第5天,活动详情查看: 更文挑战

本文已参与 周末学习计划,点击查看详情。

前言

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

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

image.png

小老弟,这满屏的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记录时一脸懵。如果对你有帮助,点个赞就好,如果有错误欢迎指出交流。感谢阅读~

PS: 今天是参加掘金更文挑战的第5天啦,没有存稿的我,周六依然战战兢兢的努力更文,不知道什么时候才能一小时搞定一篇博客呢?

虽然没多少人看,也还是给自己引引流吧~ 更文挑战的文章目录如下:

文章分类
开发工具
文章标签