晚上实在是睡不着, 起来把这个坑填了. 其实想写这篇文章好久了, 因为一些不好的习惯吃了一些亏, 加上团队中发现的一些问题, 记下来, 时刻提醒下自己.

1. 提交日志

必要性:这个我想应该不需要强调吧, 最基本的东西, 一般稍微严格些的团队都会有硬性的要求. 这是一个利人利己的工作, 想知道自己几周前干了什么, 看log是最佳的方式了.

准确性:提交信息应该是准确的描述你这次提交干了些什么, 其他的前戏和废话则不要有. 如果有需要强调的地方, 还应该备注出来. 而且一个团队应该有约定的格式, 比如 fix issue xxx, add xxx,这样会在后期日志定位时非常的方便.

2. 一次提交只做一件事

这样子是为了方便以后revert 和 merge 操作, 举个栗子,比如你一次提交了两个功能, 但是其中的一个功能可能被砍掉或者会引发一个非常严重的bug, 改动的文件非常多, 必须使用revert操作, 然后就傻逼了, 另外一个功能也被回滚掉了.再比如, 你需要merge同事的代码, 但他的一个功能目前你不需要或者合并后会出现问题, 这时候肯定会在内心问候对方的.

因此, 需要我们掌握的一个技巧就是分多次提交工作区的更改, 是的, 我见过一个同事每次必须一次性吧所有更改都提交完, 然后在日志里写: 1.xxx 2.xxx 3.xxx, 何必呢! 分多次提交可能会导致某一个版本无法正常运行, 因此一定要仔细检查.

3. review 你的更改

这点中的十分重要, 但也是最容易忽略的一些. 一定要在提交前挨个对比文件的每一处更改, 这个可能会花费你的一些时间, 但相比与带来的好处这的不值一提. 在这一步你会发现一些隐藏的bug.

4. 避免无意义的提交

这是什么意思呢, 就是某些更改可能是没有意义的, 包扩一些空格, 换行, 测试代码. 这些都应该在提交前的review中删除掉. 举个栗子,比如工程的config文件中DEBUG变量,默认值为1,你可能在这次提交时改成2, 那次提交时改成3, 最后又改回成1, 这样莫名的config文件在svn上就莫名多了3次版本,而且毫无意义, 这种情况下就不应该提交这个文件.

5. 确保你的程序能够运行

你可能会说这当然了, 但是你在提交前有运行过你的程序吗? review之后呢? 我想没有什么比更新下来的代码不能运行更蛋疼的事情了. 而且真的有的人在没有做完一个功能运行报错的情况下就提交代码.

6. clear 你的工作区

对于提交完还存在于你的工作区更改列表的文件, 你的选择有ignore/revert/delete, 总有一个适合你. 我曾经见到一个同事提交完后svn中还充斥着数十个更改文件, 分散在各个目录中. 导致每次提交都得”精挑细选”下. 一个干净的工作区绝对是一天好心情的开始!!!

因此, 一个最佳的commit流程应该是:

test –>> review –>> test again –>> commit –>> clear

我希望被我提到的同事不要生气或愤怒, 因为我坚信一句话: 和聪明的人一起共事最大的好处是不用顾忌对方的自尊心!