【转】版本控制流程

大家在项目过程中是否会经常发生以下问题：
1、测试人员在测试阶段更新测试环境时，发现编译不通过，或者应用出现异常，无法进行测试。后来发现的根源是测试和开发共用一个分支。
2、有一天某个人群发了一条邮件通知，“我们的项目代码已经发到主干，这段时间大家不要修改主干信息”，这样影响其他项目的正常发布。
3、项目进行了比较长的时间，等最后发布，需要与主干进行合并的时候，出现大量的冲突，几乎没法处理。而且冲突处理完后我们还需要重新

    再做测试，以保证我们的冲突处理没有问题，这样又需要花费大量的时间。

版本控制流程目标：
1、保证各个环境(开发、测试、主干)的独立，避免相互影响。
2、减少最终发布时合并主干出现冲突的概率。
3、降低冲突处理的难度。

原则：多个版本（开发版本，测试版本，发布版本）；多次合并。

流程：
1、项目开发编码前从当前主干建立一条开发分支，供项目开发人员使用；
2、开发结束，提交测试的时候，从当前主干建立一条测试分支，将开发分支合并到测试分支上，供测试人员进行测试。这样开发人员对开发分支的修改不会影响测试环境；
3、bug fix的时候我们定时将开发分支的修改合并到测试环境中。
4、回归测试的时候，从当前主干建议一条发布分支，将测试分支合并到该发布分支上，在发布分支上进行回归测试。
5、发布前，将发布分支合并到当前主干。

好处：
1、多个版本相互独立，互不影响
2、通过多次与主干的合并，这样发布时候和主干做最后一次合并的冲突会大大减少，并且在与主干多次合并过程中的冲突解决都在测试阶段中得到了测试。

建议：如果项目的周期比较长，和主干进行合并的次数也应该加大，以降低处理冲突的难度。