GIT 分支管理办法(二)

发布时间:2024年01月12日

GIT 分支管理办法(二)

一. 大型项目分支管理中存在的痛点

大型项目中需求的上线存在很大的不确定性,而且往往存在多版本、多团队、多开发并行的情况。尤其是大型企业对上线分支中编号的管理十分严苛,严禁夹带上线。这时对于开发而言,没有一个好的分支管理策略就是一个灾难。

二. 实践中的分支管理最优解:按版本、按需求、按人员拆分支(基础

1. 业务场景

10月份有四个需求同时在开发,分别是商机、客户、目标、业绩。其中商机需求由甲(张三、李四)、乙(王五、赵六)两个团队配合开发。其中商机需求在 20231004202310112023101820231025 四个版本都有改动,甚至互相冲突。

2. 业务特点
  • 版本多20231004202310112023101820231025
  • 关联方多:任意一侧都可能导致无法投产
  • 不同版本改同一需求:可能冲突
3. 如何处理分支问题呢?
3.1 环境为前提

准备最少三套环境用于开发测试使用

  • DEV开发分支,所有大版本排期以内的需求的分支均可以合入
  • SIT测试分支,所有大版本排期以内的需求的分支均可以合入
  • UAT预上线分支,只有正常提测且按期上线的需求相关分支可以合入
3.2. 拉取个人需求开发分支
  • 张三 商机 1004 需求:DEV-20231004-OPPT-ZHANGSAN
  • 张三 商机 1011 需求:DEV-20231011-OPPT-ZHANGSAN
  • 张三 商机 1018 需求:DEV-20231018-OPPT-ZHANGSAN
  • 张三 商机 1025 需求:DEV-20231025-OPPT-ZHANGSAN
  • 李四 目标 1004 需求:DEV-20231004-GOAL-LISI
  • 李四 商机 1018 需求:DEV-20231018- ACHIEVEMENT-ZHANGSAN
4. 实际中的操作

严格来说,上线分支一定是测试过的分支,故而生产投产分支即为 UAT 分支。但实际中,可以存在上线前几天突然通知延期的情况。当出现这种情况时,需要基于 UAT 分支拉取 PRDO 分支,将不上线的需求通过 revert commit 的形式回退代码,再通知测试重新验证该需求。

文章来源:https://blog.csdn.net/DreamStar2560/article/details/135547230
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。