版本控制的5条建议

建议1:关于版本控制系统

尽管已经2014年了,但我还是得对一部分人说:别再用VSS了。

它太老,访问方式有限,容易出故障,还有太多的缺点我不想一一列举,它甚至不是一个真正的版本控制系统(关于Atomic的支持)。

Once upon a time,CVS难配置,对Windows的支持也不好。现在我们有SVN,有更新的Git、Mecurial,各操作系统的支持也很好,微软不是也推出了TFS么?

所以,就是别再用VSS了。

建议2:Commit early, Commit often

老生常谈了。每次提交都能成为一个还原点便于追溯,否则巨大的changeset不便于管理。

我看到更多的情况是因为团队在持续集成方面的功力不够,常常一次鲁莽的Commit导致编译失败而阻碍了整个团队的进度,还有费时费力的回溯过程,导致管理者往往会因噎废食做出限制Commit的决定。

“每天6点以后提交当天代码,项目编译成功后全员才可以下班”,听起来耳熟么?

非战之罪。

建议3:在Commit之前该做的

  • 仔细检查你提交了哪些文件,不多不少
  • 仔细比对你做出的变更
  • 为Commit认真写有意义的注释

如果你不能做到Commit early, Commit often的话,以上三条的难度也会提高。

举例来说明什么是完全没有意义的注释:“更新代码”、“修改Bug”、“修改文字错误”、“版本1024”。

有些团队会倾向于将Issue的内容保存在外部系统,在注释中只用Issue Number作为索引,我认为同样不可取。

建议4:什么应该纳入版本控制

对于项目来说,没有纳入版本控制的东西是不存在的。

  • 除了代码,文档也要纳入版本控制
  • 项目引用的外部的Lib和Package需要纳入版本控制
  • 数据库也能版本控制

项目引用的外部的Lib和Package,版本会更新,导致旧版本过时不再Available,对于一些开源项目来说,甚至有项目终止的可能,所以将这些引用作为项目成果的一部分纳入版本控制是稳妥的做法。

数据库是项目成果的重要部分,自然有版本控制的必要,只是一直以来实施的难度较高。现在类似Red Gate等厂商推出了不错的数据库版本控制产品,使这个过程变得简单。数据库的版本控制不应该再是可选项。

建议5:什么不应该纳入版本控制

  • 项目的编译输出不应该纳入版本控制
  • 个人的用户配置不应该纳入版本控制

编译输出 = 程序代码 + 编译配置。既然程序代码和编译配置已经纳入版本控制,就不必重复保存。更不论编译输出在完成之前的临时属性以及尺寸问题。

Leave a Reply