如何理解版本控制系统

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

版本控制系统的历史

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

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

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

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

使用版本控制系统

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

尽可能版本化所有的东西

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

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

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

尽可能方便团队协作

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

尽可能详细记录历史

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

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

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

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