版本管理是软件研发管理中比较容易忽视的一环，这当然是比较好理解的，因为版本管理毕竟和具体业务关系不大。其实，版本管理是很多更高级管理制度的基础，如果版本管理做得糟糕，类似代码审查一类的工作就很难高效方便的执行。
下面介绍目前我们研发团队建议实行的版本管理制度，仅供参考。
1 工具软件：SVN 和 Beyondcompare
SVN是代码备份软件，Beyond compare 是代码对比软件
2 版本日志
我们要求，每个项目都应当有自己独立的版本日志文件，小的项目或者模块版本日志可以 TXT格式，大的可以用 excel 来保存。
版本日志顾名思义，就是记录项目版本演进的历史。它应当包含的内容有：序号、版本号、提交时间、作者、新增功能、修复bug列表和依赖模块信息。
版本日志存放的目录一般是项目根目录的 ./doc 子目录，直接存放到项目根目录也很好。
序号：每提交一次，序号加一。
版本号：要求每次提交都采用唯一的版本号标示。版本号一般由数字加字母组成，如 V 1.05a 这个版本号，“1.05 ”描述的是软件功能集合，也就是说，V 1.05b、V 1.05c 的功能和 V 1.05a 完全一致，a、b、c 代表软件修复的bug 在减少。
提交时间：版本提交SVN的日期。
作者：提交人。
新增功能：软件新增加的功能列表，只要软件功能增加，则版本号的数字也应当增加，若某版本没有新增功能，则版本号数字不应当变更。新增功能的描述详尽程度以产品经理或者测试功能师能理解为准，太详细了也没必要，过于简单或者有歧义也不行。
修复bug列表：如果修复的bug 是测试部门报告的bug，则用 bug编号记录。如果是研发自己发现的 bug，则应当简要描述bug 现象，方便测试工程师验证。
依赖模块信息：稍微大一点的项目，必然会依赖于大量的独立模块，这些模块可能是第三方开源模块，也可能是公司其他部门或者团队提供的模块，当然，也可以是自己研发的通用功能模块。这些模块名字、版本号必须在版本日志中描述，尤其是这些模块的变更信息，应当明确的进行描述。
版本日志的注意事项：我们明确的规定，如果既没有新增功能，也没有修复bug，则不允许进行代码提交。在很多团队的研发实践中，常常把 SVN 当做日常研发的代码备份工具，代码稍微写了一点，就马上进行提交，比如在开发某一个功能时需要3天时间，有些工程师会有每天下班提交成果到 SVN 的习惯，这种习惯不能说不好，但是我个人感觉不是最好，我相信过多的冗余信息会把真正有用的信息掩盖，所以，我建议的原则是只把真正有用的信息保存下来，同时要求，所有有用的信息都必须保存下来！对一个软件的开发工作而言，新增功能和修复bug 是我们编写代码的全部目的，因此，我们就只关注这两点，而过程则不在项目SVN中记录。
3 提交内容
提交内容应当包括：版本日志、相关代码和资源文件等。
提交的内容应当是完整的、可编译的。这句话的意思是，其他同事在一个新的机器（开发编译环境自己可以安装）上把代码从SVN上Check Out 下来后，可以顺利完成项目的编译。某些项目编译环境有一些特殊的需求，比如要打一些特殊的定制补丁等，对这样的项目，开发人员有义务在 SVN 的 ./doc 目录下进行详尽说明，并完整上传定制补丁在 ./patch 目录下。
在公司有配置管理员的情况下，建议项目编译生成的 bin 文件（即项目成果，如 exe、DLL 或者 *.so 等）由配置管理员编译生成并提交。在没有配置管理员的情况，对重大项目，我们建议采取交叉编译提交的方式，即开发人员只负责提交自己的代码，然后相互编译其他同事的代码和上传别人的 bin文件。这种管理方式有时候可以提前避免很多非技术性纠纷。
开发人员在提交代码前，必须对完成的功能和修复的bug 自己做一次冒烟测试，即冒烟测试原则上应当研发人员自己完成。
对于代码编译过程中产生的一些中间文件，典型的如 *.obj、*.o、*.s 等文件，严禁提交到 SVN。很多工程师提交这些文件的原因主要是对 SVN 不熟。
另外，需要着重指出的是，提交的代码，应当是和版本日志中描述的新增功能和修复bug 相关的。在实践中，有工程师在编程时会发现以前某些代码文件的版式不漂亮、代码注释太多等等，然后就随手做了一些修改；另外就是在提交代码时，某些正在进行中的功能开发代码也顺便做了提交。就我个人的建议，这不是好的做法，我们应当尽力避免。因为版本日志是版本管理的总纲，版本日志的核心又是新增功能和修复bug两项，这意味着我们提交的代码是围绕着这两个核心进行的。在SVN的提交日志上可以清楚看到每次提交的代码文件名，如果按照规定做的话，这些文件名应当是完整说明了版本日志中对应的功能和修复bug所需要新增或者修改的代码文件，在这里，我不希望出现冗余信息，理由前面说过。
4 提交时间
我们建议采取以功能点和修复的bug为线索的提交方式，即完成一个功能或者修复一个bug 后就立即提交。
先把提交版本和发布版本的概念做一个清晰定义。提交版本意即开发工程师完成若干功能或者修复若干bug 后，把代码上传到SVN服务器，而发布版本意即由配置管理员从SVN更新到最新代码，并进行编译和bin提交，然后把bin发布给测试部门。
我们建议采取的是多次提交对应一次发布的原则，而很多研发团队事实上采取的是一次提交对应一次发布的原则，即在版本发布的截止时间点做一次匆忙的提交活动，这种方式是可能存在一些隐患的。
5 优势
采用这样的版本管理方法，研发团队是可以获取很多好处，也可以在流程上预先排除一些隐患。当然，自卖自夸不是好习惯，所以这部分我只是简单的说几点，真正的益处，是要大家在实践中去体会的，当然，可能也还有缺点也不完善，这也需要大家在实践中去发现。
有些工程师出于各种原因，可能没有完整提交代码，对这种现象，我们采取了增加配置管理员编制的方法来解决。
有些团队一方面提交的代码和最终生成的bin 不一致，另一方面，SVN服务器上的bin 和测试的bin 又可能不一致，对这种现象，配置管理员的设置解决了前者，而通过开放SVN上 ./bin 和 ./doc 两个目录权限给测试部门可以解决后者。
测试工程师对于发布的版本可以采取增量测试的方法进行测试，减少测试工程师系统测试的次数，这样可以极大的提高测试工程师的工作效率。所谓增量测试，指的是只测试和验证发布版本的新增功能和修复的bug。
刚发布的版本很快就被测试打回，这个现象的原因很复杂，但是，通过研发人员自己完成冒烟测试可以极大缓解该现象。
有利于培养研发工程师对待代码的严肃性，为代码规范等一系列规定创造一个比较好的环境。
现在回归测试更方便和有效了。研发工程师通过回归测试的方式可以更容易的排查bug了。
有些团队测试平时很空闲，一发布版本就很忙，甚至有可能要搞通宵。现在我们通过多次提交对应一次发布的方法来解决这个问题。测试平时就可以随着研发的进行先把提交的版本测试起来，极大的提高的测试的工作效率，使得测试工程师的工作量安排分布更加均匀。
最大的好处是，使得团队内部互相 code review 成为可能。Code review 是在研发阶段消灭软件质量最好的方法，也是促进新手程序员成长的最高效方式。在严格的版本管理制度下，每个功能、每个bug 对应修改的代码在SVN上可以简明的看到，这极大的方便了资深工程师对新手代码的审查，同时，也极大的方便了新手程序员向资深工程师的学习。我一向的观点是，软件工程师把一个功能完成算不得什么，如果百分制的话，完成功能最多得30分，我们除了功能，还应当考虑稳定性、可靠性、可扩展性，还有注重代码的可读性和可维护性等等，这些东西新手程序员是很难全面兼顾的，这就需要资深工程师进行现场指导，结合新手工程师自己写的代码进行讲解，这是最快速的优秀程序员培养模式。