对于项目开发过程中,会出现以下的一些情况:
(1)对于某个项目开发了一定的阶段,决定发布一个初始版本V1.0;
(2)V1.0版本上线,对于该项目继续开发(可能增加新的特性、功能升级等升级至V2.0),此时对于原先的代码已经进行了改动;
(3)此时在V1.0中发现了一个BUG,需要马上改动,或者需要在V1.0中紧急加入一个特性,需要对于源代码进行修改了。
没有版本控制,这个时候麻烦来了。考虑一个原始方式(自己上学的时候就这么干过):
(1)开始对于V1.0版本项目拷贝一个文件夹,作为备份;
(2)对于新的版本开始在V1.0上面开发,这个时候代码或许已经变动很大了;
(3)需要对于V1.0进行修改,则对于原先V1.0备份代码再拷贝一个目录,修改其中BUG,进行加入一个特性;
(4)当对于V1.0的代码修改完成后,转向开发中的V2.0版本,此时,如果将两边的代码进行统一合并,即:对于V1.0的BUG、紧急特性也同时更改到V2.0中;
(5)Ctrl+C、Ctrl+V,删减代码,呵呵。。。混沌了。。。。。基本上确定无疑的会导致代码不一致。
采用CVS、SVN等,可以管理了:
(1)对于V1.0开发完成,进行上线了。此时对于该版本使用“TAG”标记-V1.0_Release,"Tag“为代码某个时间点的快照(不能够在快照上面进行修改);
(2)继续进行V2.0代码的开发;
(3)需要修改原先的V1.0代码了,此时通过TAG标记获取当时的代码快照(如果此时直接进行修改,然后commit提交会报错,不能直接在TAG版本上面进行修改);
(4)基于该Tag版本,建立Branch程序分支,作为V1.0_Release_r1;
(5)在V1.0_Release_r1分支上修改BUG,增加紧急特性;
(6)在原先的V2.0代码中并行进行开发,此时两边可以同时进行;
(7)V1.0_Release_r1对于BUG等处理完成之后,发布,作为V1.1上线;
(8)此时原先在V1.0_Release_r1修改的BUG,在V2.0中,仍然存在,再进行”Merge“,增加到V2.0中;
(9)OK。一切都结束了。
随便写写。呵呵