Git分支模型（参考AONE FLOW）

Git分支模型（参考AONE FLOW）

分支定义

1. master

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

2. release/xxx

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

3. feature/fixbug/hotfix

   1. 临时分支
   2. 用于开发的具体功能特性和修复bug的分支，功能完成后删除
   3. 格式为：feature_KaTeX parse error: Expected group after '_' at position 5: date_̲name_KaTeX parse error: Expected group after '_' at position 26: …n fixbug_̲date_KaTeX parse error: Expected group after '_' at position 5: name_̲description
      hotfix_KaTeX parse error: Expected group after '_' at position 5: date_̲name_$description

   分支策略

   1. 规则一

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

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

   2. 规则二

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

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

   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. 提交上线申请上线

   例子

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