持续集成回顾暨点滴分享[5] – 吐槽篇，代码提交记录很重要！

写了几篇干货，插一个吐槽吧！
持续集成的一个题中之义就要充分获取各种信息为我所用，掌握了信息，才可以避免被动挨打的局面，各位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（[b]gitlab.org）[/b]
如果你使用Gitlab，在如下所示位置可以订阅指定branch代码提交RSS

RSS真心好东西，让经过事先挑选、过滤的信息主动来找你！
一旦各种各样的信息实现了高效聚合、实时推送，谁用谁知道！
gerrit（https://code.google.com/p/gerrit/）
如果你使用Gerrit，同样也可以找到类似的RSS订阅点

+++++++++ 补遗 ++++++++++
自从使用了这套规范以后，为了写commit message时不至于冥思苦想，纠结不堪，不知不觉开始拆分功能点，多次提交，又符合了持续集成快速提交、频繁集成之义
天道循环，万物相通是也！