写了几篇干货,插一个吐槽吧!

持续集成的一个题中之义就要充分获取各种信息为我所用,掌握了信息,才可以避免被动挨打的局面,各位QA/测试们,你懂的!

众多信息中,代码的提交信息(svn commit / git commit / etc)是极为关键的一项,根据提交记录:

  • 在开发过程中,可以使我们快速、实时了解开发进度
  • 尤其是在临近上线时,密切监控代码库,防止各种未经沟通的代码提交
  • 发现Bug后,又可以方便查阅历史,定位问题
  • commit message也是代码的有机组成部分,必须严肃对待!

++++++++++++ 一个不愉快的插曲 ++++++++++++++++

我一直保持着订阅代码(开发代码 & 测试代码)提交记录,并定期查阅的习惯,每到一个新项目组,先把commit history看,信息量巨大,有木有!

来到X项目组后,嗯,我看到了如下奇葩且为数不少的commit message:

  • “艹,我居然在这个Bug上花了2小时”(老兄脏话都带到这里来了!)
  • “”(yes,这是空message,而且数量不少)
  • “联调”(你丫的,和谁联调呢?)
  • “fixed”(我猜你是修复了一个bug==!)
  • “…..字数够了吧”(你没看错,凑字数的)

当时我和我的小伙伴们都惊呆了!经过一番斗争(在会议上公开叫板)与收买(自掏腰包请开发Leader腐败)终于出台了一套代码提交规范,并使用技术手段(在SVN服务器端设置message检查)强制实施 🙂

看着真心不错,后来我自己写代码基本都遵守这套规范

+++++++++++++ 代码提交规范 +++++++++++++++++

基本格式

代码提交记录以简洁、表意清晰为基本原则,建议每个提交记录包含以下信息:[任务类别] <简述>,例如:

  • [dev] 给购物车页面增加智能搜索框
  • [bugfix] 购物车页面在Firefox下不能正常显示商品图片
  • [misc] 购物车页面文案微调

[任务类别]

任务类别包括dev、bugfix、misc几种

Δdev

功能开发相关,建议<简述>中包括任务名称及一句可以说明此次提交内容的描述性短句,如果有相应的JIRA任务,建议加上JIRA任务号。

另外非常不建议只使用一个名词作为简述:

  • 购物车Controller  =>  创建购物车Controller
  • 商品发布后端接口 => 商品发布后端接口补充一些参数

Δbugfix

代码修复相关,建议在<简述>中写明bug内容的基础上补充产生原因和解决方法

Δmisc

完全非功能性变动及杂项变动,例如:

  • [misc] 购物车页面文案微调
  • [misc] 补充注释
  • [misc] 临时代码 – 调试专用
  • [misc] 补充一个打包脚本

<简述>

务必简单明了;如果一次提交包括多个内容,建议用“1. abc; 2. def.” 分别说明。实际上更建议每次完成一个模块(功能)都单独提交

+++++++++++++ 一些工具与技巧 +++++++++++++++++++++

commit monitor(http://stefanstools.sourceforge.net/CommitMonitor.html)

开源免费,简单好用,SVN监控神器!第10001次墙裂推荐!

gitlab(gitlab.org)

如果你使用Gitlab,在如下所示位置可以订阅指定branch代码提交RSS

RSS真心好东西,让经过事先挑选、过滤的信息主动来找你!

一旦各种各样的信息实现了高效聚合、实时推送,谁用谁知道!

gerrit(https://code.google.com/p/gerrit/)

如果你使用Gerrit,同样也可以找到类似的RSS订阅点

+++++++++ 补遗 ++++++++++

自从使用了这套规范以后,为了写commit message时不至于冥思苦想,纠结不堪,不知不觉开始拆分功能点,多次提交,又符合了持续集成快速提交、频繁集成之义

天道循环,万物相通是也!

发表评论

电子邮件地址不会被公开。 必填项已用*标注