如何写好 Git commit messages

作者:程柳锋

导语

任何软件项目都是一个协作项目,它至少需要2个开发人员参与,当原始的开发人员将项目开发几个星期或者几个月之后,项目步入正规。不过他们或者后续的开发人员仍然需要经常提交一些代码去修复bug或者实现新的feature。我们经常有这种感受:当一个项目时间过了很久之后,我们对于项目里面的文件和函数功能渐渐淡忘,重新去阅读熟悉这部分代码是很浪费时间并且恼人的一件事。但是这也没法完全避免,我们可以使用一些技巧尽可能减少重新熟悉代码的时间。commit messages可以满足需要,它也反映了一个开发人员是否是良好的协作者。

编写良好的Commit messages可以达到3个重要的目的:

  • 加快review的流程
  • 帮助我们编写良好的版本发布日志
  • 让之后的维护者了解代码里出现特定变化和feature被添加的原因

先来看看一个比较好的例子,感受一下:

下面谈谈,如何让项目里面的Commit messages步入规范化,流程化。

Commit messages的基本语法

<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

Type表示提交类别,Subject表示标题行, Body表示主体描述内容。

Type的类别说明:

  • feat: 添加新特性
  • fix: 修复bug
  • docs: 仅仅修改了文档
  • style: 仅仅修改了空格、格式缩进、都好等等,不改变代码逻辑
  • refactor: 代码重构,没有加新功能或者修复bug
  • perf: 增加代码进行性能测试
  • test: 增加测试用例
  • chore: 改变构建流程、或者增加依赖库、工具等

Commit messages格式要求

# 标题行:50个字符以内,描述主要变更内容
#
# 主体内容:更详细的说明文本,建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug,增加一个feature,提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险? 
#
# 如果需要的化可以添加一个链接到issue地址或者其它文档

这3个问题给代码的变更建立了良好的上下文,可以让其他的代码review人员或者项目成员直观的判断修改点是否正确。一条良好的commit message也可以让维护者知道这个patch是否适合发布到稳定的版本中去。

如果一个patch没有回答上面的这几个问题,那么它是无意义的。它会给review的人员造成负担,让他们花费大量时间去评审讨论这个patch的作用和意义。更糟糕的是,如果一个项目实施SCM纪律,则这个patch会被拒绝掉,然后开发人员需要花费时间重新编写一个新的patch。重新编写一个复杂的patch代价是巨大的,而把commit message写好只会花费几分钟。

Commit messages书写建议

  • 尽可能多的提交,单个Commit messages包含的内容不要过多;
  • 标题行以Fix, Add, Change, Delete开始,采用命令式的模式。不要使用Fixed, Added, Changed等等;
  • 始终让第二行是空白,不写任何内容;
  • 主体内容注意换行,避免在gitk里面滚动条水平滑动;
  • 永远不在 git commit 上增加 -m 或 --message= 参数,提交的时候git commit即可;
  • 如果你是vim用户,将下面这行代码加入到~/.vimrc。这会帮助你检查拼写和自动换行。 autocmd Filetype gitcommit setlocal spell textwidth=72

使用Commitizen工具

Commitizen可以让你的commit message更加规范统一,适合项目团队使用,使用也很简单,使用npm安装后,提交代码的时候使用git cz去替代以前的git commit命令即可。

安装commitizen:

$ npm install -g commitizen

使用截图:

自动生成Change log

conventional-changelog是用来从git的元数据中生成 Change log文档的工具,只要你提交的格式满足它定义的标准,此处以angular标准为例子。使用它生成的Change log包含以下三个部分:

  • Bug Fixes Bug修复的信息
  • Features 增加的特性
  • BREAKING CHANGES 重大变更

可以参考它生成的文档CHANGELOG.md,使用如下:

$ npm install -g conventional-changelog-cli
$ cd my-project
$ conventional-changelog -p angular -i CHANGELOG.md -s

这不会覆盖你之前的CHANGE.md文档内容,会在这个文件的最上面插入新生成的日志信息。

参考链接

原文链接:http://ivweb.io/topic/58abda9d2117ae2f4995b4a8

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏JetpropelledSnake

Linux学习笔记之Linux计划任务Crontab

cron 是 UNIX, SOLARIS,LINUX 下的一个十分有用的工具。通过 cron 脚本能使计划任务定期地在系统后台自动运行。

762
来自专栏文大师的新世界

9. redux如何精简代码

通过之前的代码不难看出redux系统里的ActionType、Action、Reducer都有一定的共性,小项目无所谓,这样写更清晰,但是一旦组件以及业务增多,...

1065
来自专栏nnngu

01 整合IDEA+Maven+SSM框架的高并发的商品秒杀项目之业务分析与DAO层

项目源代码:https://github.com/nnngu/nguSeckill ---- 这是一个整合IDEA+Maven+SSM框架的高并发的商品秒杀项...

3588
来自专栏数据小魔方

R语言爬虫实战——网易云课堂数据分析课程板块数据爬取

R语言的爬虫生态虽然与Python相比要弱小很多,but,如果你真的想要用R干一些有趣的事情,那么R语言目前所具有的的网络爬取工具也能给你带来很多方便。 今天...

3334
来自专栏腾讯移动品质中心TMQ的专栏

【测试左移专栏】用 Powermock 和 Mockito 来做安卓单元测试

在计算机编程中,单元测试(Unit Testing)又称为模块测试, 是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。

2100
来自专栏阿北的知识分享

yii2开发中19条推荐实践

这个是做yii2开发的基石,除非没有办法使用,否则请不要放弃,除了更容易的安装yii2及第三方扩展外,能使用Composer代表着你的服务器最少能运行起来php...

2276
来自专栏达观数据

达观数据基于RequireJS的前端模块化设计

伴随着互联网的飞速发展,web中对于前端的要求越来越高,前端的代码的代码量、复杂度与日俱增,带来了诸如前端代码复用率低,难维护等问题。针对这些现有问题,达观科技...

2425
来自专栏琯琯博客

Git 提交规范

一直是 ESLint 的忠实用户,深知规范的重要性。然而,在新项目交接中,我被 Git Commit 规范逼疯了。才意识到自己的疏忽,于是便有了一探究竟的想法。

522
来自专栏DevOps时代的专栏

你可能会忽略的 Git 提交规范

一直是 ESLint 的忠实用户,深知规范的重要性。然而,在新项目交接中,我被 Git Commit 规范逼疯了。才意识到自己的疏忽,于是便有了一探究竟的想法。

802
来自专栏nnngu

01 整合IDEA+Maven+SSM框架的高并发的商品秒杀项目之业务分析与DAO层

Github:https://github.com/nnngu 项目源代码:https://github.com/nnngu/nguSeckill

61710

扫码关注云+社区