关于版本控制的思考

1. 对于一个公共的配置文件，可能一个产品的很多模块都在使用，经常会出现并行修改。我们需要将这个配置文件按照各个模块进行分拆吗？

驳斥：这本身就是版本控制工具的优点之一。对于公共配置文件而言，使用版本控制的并行修改再diff-merge 很好的解决了将文件按照功能进行分布造成的文件的繁多和复杂。

但是，如果该文件不是文本格式。比如对于开源的自动测试框架 Robot Framework，Test case 全是html的，内部都是表格，diff 不能很好的分辨出文件更改的部分，于是，就变成了最原始的手动diff，然后手动merge，当文件越来越大，带来的后果也许是灾难性的。按照功能对公共文件进行切割未必是个坏的、完全做无用功的方案。

2. 在对代码进行更改后，还需要在后面加上 // Modified by Chris, 2009.02.16. 类似字样吗？

驳斥：那干脆别用版本控制工具了。

的确，这个问题的争论在很多bbs上都看过了。使用任何一个版本控制工具，完全可以通过历史记录查到某某时间某某人修改过哪几行代码。但对遗留代码的更新时，加上自己的签名未必是个坏事儿。我们可以迅速地知道曾经改过那几行，以及在出现错误时，迅速去定位是否是自己更改的代码跟原先的代码冲突或者矛盾。

3. 在更改过bug时，是否需要在更改的语句后面，加上 // Bug fixed : why, how, pay attention. 等来描绘出现bug的条件，如何解决的，以及未来需要注意的。

驳斥：版本控制工具在提交时是可以添加comments的，添加上提交所更改的东西就可以了。或者可以使用其他的 bug trace 工具。

这样做当然是可以的。但比如后来，有人需要去进行代码的更改，刚好改了这一行，也许以前辛辛苦苦更改掉的bug，又出现了。但如果有这句注释在后面，在别人进行更改的时候，看到这行话，他就会知道，奥，这个地方可能会出现这样一个bug，需要注意这些东西。。。，也许代码质量会因此更高。

也许，上述的几个问题，对于某些人来讲可能嗤之以鼻，他会拿出一系列的解决方案来完美的解决这些问题。OK，那是好事儿。我在这儿想说的是，版本控制只是一个工具，不需要教条的为了遵守而遵守，有时候，一些不规范，不是末日。

Keywords: version control;