① 从主干拉出分支B1， 开始在B1上进行需求开发，B1版本进入开发状态，B1版本的里程碑基本确定，包括需求列表， 提测时间，测试进度，封板时间
② B1版本需求开发完成，转测试组测试版本，包括设计文档已经评审定稿，B1版本进入测试状态
③ B1版本提测之后，将B1版本代码合并到主干
④ 测试组测试B1分支的需求，如果有bug，对于修改的代码， 相关开发人员需要同步提交到B1， B2分支
⑤ 将B1的分支合并到主干之后，从主干拉出B2分支进行开发
⑥ 开始B2分支的需求开发，模式同B1
⑦ B1分支需求测试完成，版本封板，分支冻结，禁止提交代码，B1版本进入发布状态
⑧ 打版本发布TAG R1.0，上线版本从R1.0上打包
⑨ B1上线的版本上出现的严重的bug，需要紧急修复， 打开B1冻结状态，修复完成，修复的代码需要提交到B2版本上，如还有其他高版本也需要提交
⑩ 打版本发布TAG R1.1， bug修复的版本从R1.1上打包
开发策略：
版本状态有开发，测试，发布三种状态
开发只能在分支上开发，提交代码，不能在主干开发
主干上的代码只能是从分支同步过来
TAG是只读状态，不能提交代码
在低版本上修改的bug要提交到高版本上线
最多有两个版本在开发状态，一个版本在测试状态
版本的需求统一提测，部署到测试环境
实践敏捷开发测试，测试人员可以在集成开发环境提前测试验证需求功能，尽早将缺陷反馈给开发