基于上线时间点拉分支

• 如分支A：2023.06.29；和 分支B：2023.07.18 两个上线节点，从master拉分支，上线后合入master。master分支始终保持为当前生产运行的代码。
• 缺点
  • 需要提前规划哪些需求，在不同的时间节点上生产。应对需要提前上生产的需求，紧急的需求都不够灵活。
  • 无法灵活应对需求的时间节点变动。如果有需求甲，本来要计划合入分支A，sit或uat测试到一半，由于一些外界原因，要改为分支B甚至更后面的分支C，这个时候要把A分支的需求甲的代码删除
  • 无法配合外部系统的强时间节点且周期长的需求。如从6月1号开始，现有1-10个大需求跨多个业务部门，必须配合其他微服务同时在6月1号起在sit上运行，其中需求1到3是6.29上生产，需求4到7是7.18上生产，需求8到10是7.30上生产。
  • 在sit和uat的测试时间特别紧凑。如06.29的分支正在sit验证中，留给07.18的在sit验证的周期就较短。
• 优点：
  • 环境扩充时更便捷
  • 环境切换时通过脚本切换，不同环境代码不一致的风险极低
• 适用
  • 上游服务、聚合服务（调别人的）

基于环境创建分支

• 会创建prod，uat，sit分支，开发时从prod拉出feature分支，feature分支开发完成后，分别合入sit，uat，prod。prod分支始终保持为当前生产运行的代码。
• 缺点
  • 目前有三个环境要合三次代码，如果环境更多时要合的次数更多，每次都需要手工合入
  • 每次合入不同环境的分支时，可能会合入代码时冲突，包括会有代码漏合的风险
• 优点
  • 各个环境发版时间灵活
  • 不同的环境的需求数量可以不一样，可以灵活对接其他微服务的需求
  • 可以安排充足的时间在sit和uat验证、联调；例如一个大的跨多个服务的需求，需要在sit测试半年，都支持。
• 适用
  • 下游服务（给别人调用的）