Git分支模型(参考阿里Aone Flow)

分支定义

1. master

   长期分支，存在与整个项目开发过程。
   
   由项目主要技术负责人管理该分支。

2. release/xxx

   release/test 和 release/prod
   既可以为长期分支也可以为短期分支，可能存在于一个或者多个版本之间.
   
   由测试负责人负责人管理该分支。

3. feature/fixbug/hotfix

   临时分支
   用于开发的具体功能特性和修复bug的分支，功能完成后删除.
   格式为：feature_$date_$name_$description
          fixbug_$date_$name_$description
          hotfix_$date_$name_$description

分支策略

1. 规则1

   开始工作前，从主干创建特性分支

   • 每当开始一件新的工作项（比如新的功能或是bug）的时候，从最新已发布版本的主干Master上创建一个以feature(bugfix)/前缀命名的特性分支，然后在这个分支上提交代码修改。
   • 每个工作项（可以是一个人完成，或是多个人协作完成）对应一个特性分支，所有的修改都不允许直接提交到主干。

2. 规则2

   通过合并特性分支，形成发布分支

   • 从主干上拉出一条新分支，将所有本次要集成或发布的特性分支依次合并过去，从而得到发布分支。发布分支通常以release/前缀命名。
   • 每条发布分支与具体的环境相对应，比如release/test分支对应部署测试环境，release/prod分支对应线上正式环境等等，并与流水线工具相结合，串联各个环境上的代码质量扫描和自动化测试关卡，将产出的部署包直接发布到相应环境上。
   • release/prod从master上拉取的时候master可能已经有其他更新上线了，此时从master拉取拉取的release/prod合并相关feature分支后需要进行回归测试。
     

3. 规则3

   发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支

   • 完成了线上正式环境的部署，就意味着相应的功能真正地发布了，此时应该将这条发布分支合并到主干。
   • 为了避免在代码仓库里堆积大量历史上的特性分支，还应该清理掉已经上线部分特性分支。
   • 主干分支上的最新版本始终与线上版本一致，如果要回溯历史版本，只需在主干分支上找到相应的版本标签即可。
     

4. 其他

   • 对于hotfix，可以创建一条新的发布分支对应线上环境（相当于hotfix分支），同时为这个分支创建临时流水线，以保障必要的发布前检查和冒烟测试能够自动执行。
   • 如果非得修一个历史版本的Bug，在主干分支找到版本标签位置，然后从那个位置创建hotfix分支，这种情况比较少见

开发流程

1. 新功能开发时，开发人员从Master拉取代码生成特性分支。

2. 单元测试完成后等待测试负责人拉取release/test分支，然后提交Pull Request

3. 开发负责人或者其他开发人员对Pull Request进行代码Review

4. 代码Review完成后，测试负责人合并Pull Request到release/test，如果遇到合并冲突，则让相应的开发人员把feature/bug/hotfix分支重新以master为基准进行提交以及让相应的开发人员协助解决。

5. 测试人员使用流水线工具进行代码质量扫描和自动化测试

6. 测试人员进行测试

7. 完成测试后，查看Master是否比拉取release/test时有更新，如果没有直接使用release/test上线，否则从最新Master拉取分支release/prod分支合并相关PR并进行回归测试

8. 提交上线申请上线

   示例：

   开发人员A从Master拉取代码生成feature_20190818_A_get_users
   开发人员B从Master拉取代码生成feature_20190819_B_login
   
   测试负责人Y从Master拉取release/test
   开发人员A提交Pull Request PR1
   开发人员B提交Pull Request PR2
   
   开发负责人F和开发人员C评审PR1 PR2，评审通过
   
   测试负责人Y合并代码到release/test
   测试人员X进行测试，完成后发现Master和拉取release/test时一样，直接使用release/test进行构建申请发布