如何理解版本控制系统
版本控制系统在当今的软件开发中，被认为是理所当然的配备工具之一。应该现在很少有人对于“版本控制系统”的好处的理解还停留在所谓的代码备份那么简单吧。这里说下个人对版本控制系统的理解。
版本控制系统的历史
版本控制系统作为软件开发中的一个必备工具，回顾下这个工具的发展历史，也有助于理解这个工具都解决了软件开发中的什么问题。
版本控制的历史最早可以追朔到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