如何理解版本控制系统

版本控制系统在当今的软件开发中,被认为是理所当然的配备工具之一。应该现在很少有人对于“版本控制系统”的好处的理解还停留在所谓的代码备份那么简单吧。这里说下个人对版本控制系统的理解。

版本控制系统的历史

版本控制系统作为软件开发中的一个必备工具,回顾下这个工具的发展历史,也有助于理解这个工具都解决了软件开发中的什么问题。

版本控制的历史最早可以追朔到20世纪60年代[1],总结来说就是:

  • 借助人工来进行版本控制
  • 本地版本控制系统
  • 集中式的版本控制系统
  • 分布式的版本呢控制系统

这里顺带提下,版本控制系统提供的3个能力[2]:可逆、并行、注解。也就是可以回到任何一个软件版本、大家可以进行协作开发、可以详细记录代码的变更情况。

使用版本控制系统

从版本控制系统的发展历史可以看出,版本控制的重要性,远远不是单纯用于备份那么简单。还包括:

尽可能版本化所有的东西

不要仅仅将项目的源代码纳入到版本控制下,也应该包括网页、文档、FAQ、设计注释和任何人们希望编辑的内容[3]

但这个可能又会被滥用,所以要特别说明:

  • 一般是将会变化的纳入版本控制,比如:源码、文档等。
  • 而不会变化的就进行归档即可,而非版本化,比如:邮件。
  • 由于当前版本控制系统对二进制文件的变更展现支持不是太好,所以有些文档建议用纯文本方式管理,比如:reStructuredText、MarkDown。
  • 生成的文件就不要纳入版本控制了,比如:源码编译出来的二进制文件。

尽可能方便团队协作

  • 在CVS流行前,还只能对单个文件进行版本控制,后来的Subversion的流行,又是对CVS的进化。
  • 善用分支,避免开发过程中的瓶颈,比如:Git等分布式版本控制系统的流行,对分支的处理更加自如。
  • 项目的版本库应该能够通过Web浏览。这不仅是意味着浏览最新修订的能力,也包括回到过去查看早先的版本,查看修订之间的区别,以及阅读针对特定变更的日志信息等等[3]。很多版本控制系统都有周边的软件支持,比如:Trac、GitHub、GitLab等。
  • 让大家都知晓版本变化的细节。
  • 有一定的权限或授权控制。

尽可能详细记录历史

  • 可以知道哪个版本的哪个文件的哪行代码的原作者是谁。
  • 谁在什么时间进行哪些改动。
  • 按一定约定规范记录变更日志。上面2条,可以由版本控制系统本身来处理,这一条就得看大家项目内部的规范执行力了。

尽可能多的记录软件开发中产生的常见行为

是第一条,“尽可能版本化所有的东西”的扩展,也就是广义上的配置管理,包括:

  • 需求分析、构架设计行为。常见的就转化为对应文档
  • 开发行为。就是大多数程序员喜欢编写的,常见的编写项目代码、产品代码、功能代码。并且,最终用户/客户日常用的软件或服务,也是运行这些代码。
  • 测试行为。随着TDD等开发哲学的流行,逐渐被重视。常见的就转化为对应的单元测试代码、功能测试代码(为了将人工测试行为代码自动化,这样这个行为也被记录到版本控制中了)
  • 配置/部署行为。所谓DevOps的复古的开发哲学流行,也慢慢被接受。常见的就转化为配置文件、部署脚本、运维脚本(更重视配置文件,推行约定大于配置,行为脚本化、工具化、自动化,这样这个行为也被记录到版本控制中了)

参考

注解

[1]http://blog.jobbole.com/14489/
[2]http://www.catb.org/~esr/writings/version-control/version-control.htm
[3](1, 2) http://producingoss.com/zh/vc.html

注解

这篇是个人总结的《软件构建实践》系列的一篇文章,更多更新内容,可以直接在线查看:http://pm.readthedocs.org。并且部分内容已经公布在GitHub上:https://github.com/akun/pm