起始阶段：

　　项目开始项目组只有从第三方获取类库、具备编程知识员和PM（项目经理）由于成员数量不少使用简单共享方式版本管理往往难以胜任某些人往往会新功能需要或者无意将些代码改得面目全非无从追踪我们需要个简单版本管理工具比如Visual Source Safe每个人在修改代码之前要求先将代码文件标记为“检出”状态每次“检入”代码都在服务器上生成个新版本好了所有代码都有了版本记录我们可以查看代码演进过程对任何两个版本进行比较也可以轻松获取到早先版本

　　开始迭代：

　　由于客户要求项目开始进行简单迭代PM要求所有人员检入可以工作代码然后开始执行构建第次全部构建过程可能并不顺利有人修改了A组件导致了依赖A组件B组件不能正常工作了当然这个不难解决我们需要对成员进行培训要求每个人在检入代码前保证所有构建都是成功这很凑效虽然每次构建要耗费不少时间编译很容易发现但是逻辑却没有那么简单了不过到现在为止这个并不太重要毕竟项目刚刚开始迭代在给客户演示时候偶尔崩溃也是可以忍受

　　版本建立：

　　随着项目第次交付期临近PM决定停止新特性开发确定1.0版本并且将这个版本发布SIT（系统集成测试）刚刚SIT测试时候大家都忙于修改自己代码中BUG忙得不亦乐乎慢慢BUG数量曲线开始趋于平滑很多人开始觉可以将当前版本发布从而可以投入精力进行新特性开发了PM也这么认为从需求跟踪矩阵情况看还有许多工作量客户会要求在第二次交付（2.0.x版本）时候看到剩下需求都已经实现为了不影响1.0.x版本构建PM下令所有人可以在本地编辑代码以添加新特性但是不得检入版本机唯允许被检入版本机是修改BUG代码这在段时间里看起来工作得不错知道有天小王发现他在 a.java 文件中添加和编辑了许多新特性相关代码但是 现在要命是发现了个跟 a.java 相关BUG冥思苦想小王决定将a.java先备份起来然后撤销检出ok回到1.0.x代码了在a.java中修改了通检入了很幸运居然没有引起问题小王开始将原先备份 a.java和修改过BUGa.java中更改进行合并合并结果将产生个新a.java文件这个文件没有了已经发现BUG而且包含了新特性代码由于小王是高手所编写代码遵从了SRP(单职责原则)所以小王合并并没有耗费缩少时间但是接下来时间里小王又发现b.java,c.java,d.java…x.java需要进行这种手工合并每次合并他都要将文件预先备份起来而且在1.0.x稳定运行之前小王不得检入自己代码因此小王担心如果自己硬盘崩溃小王也为不能够使用其它人编写新特性代码而感到无比郁闷PM也意识到这种情况在个晚上权衡之后PM决定在版本服务器上建立了2.0.x目录将1.0.x代码拷贝到这里来Ok所有新特性开发在2.0.x中进行所有BUG修改在1.0.x和2.0.x中同时进行这真是个不错主意但是过不了多久项目组就被频繁拷贝粘贴折腾死去活来代码修改没有办法被有效跟踪则更是让人伤透了脑筋