@玛酷猫12 年前
头几年的工作也都没考虑过版本控制，一方面是和工作条件有关，那时候公司小，架构简单，开发也就1、2个人，交叉部分很少，自己做自己的就好了，另一方面自身也并没有版本控制的概念，直到09年。
那时候技术人员也将近10人，交叉工作比较多，尤其是程序人员和设计人员经常发生文件覆盖事件（那时候项目还没三层化，都混在一起），当时就想寻找一种解决方案才慢慢知道版本控制，于是便向当时领导提出应用版本控制，减少避免此类现象再次发生。虽然当时领导认同这一看法，但却没有实施，一方面可能是版本控制器没人会配置，当时并没有多余的设备用来架设，另一方面现有人员习惯了目前的开发方式，认为版本控制影响效率，版本控制推行难度比较大，最后也就不了了之，多注意多检查罢了。
PS：那是常常想当时可能不是部门负责人，没有资源推动实施，等自己做了负责人之后才发现，并不是成为领导就一定能推得动，新的思想、方法，部门绝大部分人尤其是老员工不支持甚至抵制，实施难度还是很大的。
时间到了今年年初，部门老人走了不少，新人又都比较支持的条件下，才上了版本控制器，也仅仅作为开发使用，一旦开发完毕上线后进入维护阶段，版本控制器也就不再使用，直接在运行的项目上直接修改。安全隐患也是蛮大的。不过自己离开原来单位有段时间了，现在使用状况也不得知。
说道版本控制自然也要牵扯到版本号。对于版本号都不陌生，IE6\7\8\9，office2000\2003\2007等等。这些只是简单的命名方式，常规命名方式主要有三种，以下引用百度百科：
1、 GNU 风格的版本号命名格式
主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]]
英文对照 : Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]
示例 : 1.2.1,2.0,5.0.0 build-13124
2、 Windows 风格的版本号命名格式
主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]]
英文对照 : Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]]
示例： 1.21,2.0
3、.Net Framework 风格的版本号命名格式
主版本号.子版本号[.编译版本号[.修正版本号]]
英文对照： Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]
其实大同小异的了，借用原来的网站项目，可以把每次改版作为主版本号，板块的修改和功能的添加作为子版本号，每次的小BUG修改作为修正版本号，最后一项可以用版本控制软件累加的那个计数。版本号最关键的并不是怎么命名上面，而是每次版本变动的版本文档，里面会清楚的记录每个版本添加了什么功能，取消那些设置，修正了那些bug等等。当你向别人介绍产品的时候可以很清楚的说明这个项目经历多少次更新，原来有些什么功能，现在扩展了哪些功能。别人也能了解到你这个项目的发展情况。而这个正是我们现在缺乏的地方，随便抓个人出来连最基本的所有功能都说不全，就甭提其他的了。
其实版本控制并不是仅仅是上一个软件，大家都在用这么简单的事情，它也是一种迭代开发流程和思想，同时也是文档建设的基础。在每次同步版本控制软件的时候，都会有提示添加说明，其实在这里就应该把这次源文件做的哪些变动填写好，便于自己以后查找，同时也便于团队其他成员熟悉，最后也汇成版本文档。
下一篇集中写下开发流程和文档建设。