Git多版本并行开发实践

 本文目的：

实现多个项目同时进行的git多版本管理工作流。

    名词解释：

         feature-XXXX：特性分支指CCS中一个项目或者一个迭代，在该分支上开发，完成后，合并，最后，删除该分支，开发人员(xxxx可以自己根据该分支)

         develop ：开发分支，开发环境基于该分支构建，开发人员关注该分支，一个大融合分支，该分支体现了此时进行的所有项目的特性功能。

         test（release）：测试分支，测试环境基于该分支构建，测试人员关注该分支，该分支包含即将上线的特性功能。
         
         hotfix：为了修复某个bug，从master分支上面分出来的。修复完成后，再merge到master分支以及其他分支

        master：生产环境稳定分支，生产环境基于该分支构建

目前现状：

3、产生问题：

   从上图可以看出 当前分支管理无法实现 多版本并行开发，是一个串行的工作流方式。

  1、当某个迭代在develop分支完成生命周期即封板后，此时代码进行到test分支，发现代码有bug

       目前所见做法有 部分开发者直接在test分支修改代码，develop分支不修改，等到上线后master反合；部分开发者在test修改后，develop同时改掉。

  2、同时有 A、 B  2个迭代， A迭代计划先上线，B迭代计划在A后面上线，只能A迭代生命周期进行到test才能释放出develop分支给B迭代使用。

  3、同时有 A、 B  2个迭代， A迭代计划先上线，B迭代计划在A后面上线，突然接到通知B需要在A前面上线，此时A占据着测试环境，需要增加很大工作量回退代码。

上述问题大大影响了开发效率，测试效率，也会产生代码丢失的风险等。

解决方案

 解决方案-工作流图：

        

流程图解释：

  1、场景

    项目同时并行 ：1、迭代33 ； 2、迭代22开发 这2个项目；

 2、准备

    从master拉出2个分支 feature-迭代33  2、feature-迭代22。

3、开发自测联调阶段（feature->develop）

   3.1、  负责这2个项目的开发人员在各自这2个分支上开发。
   
   3.2、开发完成，想到环境上验证自己开发东西是否ok或者和前端进行联调。可以将各自分支上的代码merge到develop分支，此时以develop分支部署开发环境，就具有了这2个项目的所有特性；
   
   3.3、如果开发环境验证时发现存在bug，此时修改代码请在各自的feature分支上修改，修改完成再将自己的分支代码merge到develop环境，部署一下验证。

4、提测阶段(feature->test（release分支）)

 4.1、到此阶段前后端已经联调完毕，自测Ok需要发起测试验证即提测，此时迭代22开发在迭代33前上线，保险起见将master分支反合到该特性分支（feature-迭代22）以及test分支，
再将test分支代  码反合到feature-迭代22分支（这么做减少冲突）最后将feature分支merge到test分支，部署test分支提测。

 4.2测试过程中发现bug，在各自分支修改，修改后合并到test分支，再部署验证，别忘了也merge到develop分支。验证 ok，选取时间点上线。

5、上线阶段(test（release）->master)

可以拿test（release）分支上线，记住上完线要反合master分支，打tag

说明：在第4步中，应该有一个release分支，但是因为环境不支持等原因，以固定的test分支代替其作用；