单一仓库分支模型的定义

分支类型一共分成 A/B/C 三大类。

分支类型-A：主干开发集成发布

其主要特点

• 向该仓库提交代码的工程师每天都能把对该库代码的修改提交到 master 上
• 在全面自动化检查和验证保护之下，提交的代码是准发布质量，可以随时提测发布。
• 也由于合入频繁，且代码质量有保障，没有拉分支的必要。
• 一旦发布的代码出现问题，就直接向主干提交修改（或通过代码级回滚），并发布新的 hotfix

分支类型-B：个人分支开发，主干集成，分支或 tag 发布

其主要特点

• 发布分支既可以是 single release branch，也可以是 multiple release branch。
• 每个人做开发工作时都有自己独占的分支，不存在多人共享分支的情况
• 该分支类型项目也可以直接主干打 tag 方式进行发布

分支类型-C：团队分支开发，主干集成，版本分支发布

其主要特点

• 发布分支可以是 single release branch，也可以是 multiple release branch。

• 存在团队共享分支，有时因大特性开发，也会拉出这样的共享分支。

  • 若无特别说明，其他章节均使用“多人共享分支”来指代本类分支。
  • 这些分支是为了将多个人的代码集成在一起，做局部质量验证
  • 有时，质量验证的手段还包括在该共享分支上对外发布产品子版本，为了验证这个分支上的特性是否质量 OK

• 个人开发时，从团队分支上再拉个人分支。

  • 个人开发分支的代码向所在团队分支合入集成。

特别说明

如果一个发布单元是 SDK 或框架类，需要针对某个特定客户提供长期定制化版本，则该团队至少应该有一个特定的长期开发分支对应该客户，主要开发活动也应该在该分支上进行。此时，该长期开发分支可视为该定制化产品的主干产品分支。其要求与一般产品主干分支的要求相近。即：每个定制化产品的分支模型均可从上述三种分支类型中找到对应的类型归属。

这种定制化产品分支的确存在，并在某些情况下是合理的，但并不推荐使用。因为同一个团队同时维护多个平行定制产品分支，存在巨大的功能同步/代码平移/重复测试等成本。而且容易形成《持续交付 2.0》第八章“常见分支开发模式”中所提到的“分支地狱”状态。

建议从产品结构/软件架构/代码结构三方面进行必要的抽象与解耦，或者使用特性开关方式，从而让相同代码在不同代码库或分支上尽可能减少重复。