案例1：这阶段公司内部在测试一个即将上线的产品，好几次都遇到运行良好的服务在某个时间段后不能提供正确服务的情况，由于产品涉及到多个端，协作人员众多，而且各端软件的更替也较频繁，在从内部排查问题的同时也在从外部着手确定是否有人更改过某个程序，众研发人员都说没有更改过程序。但是随着排查的深入往往会发现是某个人搞混了自己发布程序的版本。

案例2：团队中有人在发布动态库或应用程序时采用日期来做版本号，在频繁迭代的过程中无法使应用程序和源码管理系统中版本对应起来，不利于定位问题。

案例3：使用源码管理系统提交时为了偷懒或者忽视，不标注或随意填写改动描述，在进行代码回退时那个费劲。



版本管理的重要性在研发工作中不言而喻，缺乏规范化在研发阶段会严重影响开发效率，在测试阶段也会造成很多无意识的错误，一旦到了发布阶段造成的损失会更大。记得在一次公司规范管理的会议上，老总曾提到过我们的硬件产品由于烧录程序版本的问题给公司造成了很大的经济和声誉损失。所以如何规范化版本管理首先作为研发人员和管理人员的我们要在心里重视起来，进而采取措施去规范化版本。


源代码和文档管理：如果你的公司还没用源码管理工具进行源码管理，你出头的机会就来了，向他们推荐SVN和GIT吧（别笑，还真有很多公司没有形成企业级的规范，我就逮到这么一个机会），现在据我了解大部分商业公司还是在使用SVN，刚才案例3提到的提交改动描述的问题，SVN就没有GIT做得好，SVN可以提交空注释，于是就发现众多偷懒的程序员们一片片空白的注释，这纯粹是挖坑埋自己......。提到文档，我们程序员最最讨厌了，可是又不得不写，用一些富文本工具写出的文档无法进行内容比对，建议使用markdown来维护文档。


二进制程序的管理：对于二进制程序的版本规则，案例1给我们的教训是必须得有，案例2告诉我们版本规则必须要能够表达一定的含义或者对应一致的源文件。最通用的形式通常是major.minor.build,在新版本推出时，应更新major、minor或是build的版号，决定于变更的大小。当有极大的更新时，会增加major的版号。而当有大更新，但不至于更新major时，会更新minor的版号。若更新比较小，例如只是除虫（bug fixing），则会更新build的版号，这里的build版本号通常可以和源码管理工具的revision版本号对应起来，这样可以把应用程序和相对应的代码关联起来，在进行bug查找或修正时是个很大的便利。


小知识:在windows下利用svn的TortoiseSVN工具subwcrev.exe可以很容易获取代码的revision，配合vs的脚本工具可以很容易的写入程序中。    在linux环境下使用svnversion命令即可。