主干开发模型（Trunk-Based Development，简称TBD）是一种持续集成和快速发布的分支管理策略。与Git Flow等模型不同，主干开发模型鼓励开发人员将所有更改直接合并到主分支（通常称为main或trunk），并尽可能避免长时间的功能分支。这使得代码库保持在一个稳定、可交付的状态，以便实现频繁发布和高效的协作。

主干开发模型的核心特征

1. 单一主分支：

   • 主干开发模型的代码库一般仅包含一个主要分支，即“主干”（main或trunk），所有的开发活动都直接在此分支上进行，避免使用长期存在的开发分支或功能分支。

2. 小步快跑，频繁合并：

   • 开发人员通常将小规模的代码更改（如小的功能或修复）频繁地合并到主分支，避免长时间持有单独的分支。这样可以减少代码冲突，同时确保团队能够及时看到所有代码变更。

3. 短生命周期的分支：

   • 在需要进行较大改动或进行实验性开发时，开发人员可以从主干分支创建一个临时分支，但通常这个分支的生命周期非常短（通常几天内），并在完成后迅速合并回主分支，以减少不必要的复杂性。

4. 持续集成（CI）：

   • 主干开发模型依赖于持续集成系统，以确保每次代码更改（合并）都自动进行测试，确保主分支的稳定性和高质量。这种自动化测试流程使得每次更改都经过验证，不会因频繁合并而破坏系统的稳定性。

5. 功能开关（Feature Toggles）：

   • 为了在主分支上进行持续集成但又避免发布未完成的功能，主干开发模型通常使用“功能开关”（Feature Toggles）来控制功能的启用状态。未完成的功能可以通过功能开关禁用，以便在合并代码后不会对用户产生影响。

示例

1. 所有功能开发直接提交到main分支上，在生产上线后发现缺陷时，也直接将修复缺陷的代码提交到main分支并再次以main分支发布：

2. main分支已发布到生产环境，团队已经将下一迭代的功能代码提交到main分支上，但这时候生产环境上发现了一个缺陷，产品经理不希望修复缺陷时将新迭代功能发布到生产上。开发团队决定从tag v1.0.0的commit创建出临时的hotfix_v1.0.1分支，在临时分支hotfix_v1.0.1上修复缺陷并发布到生产环境，然后将hotfix_v1.0.1分支代码合并回main分支。

3. 使用feature-toggle暂时关闭新功能特性，即便新特性代码随着修复缺陷的代码被发布到了生产环境，也不会产生影响。

主干开发模型的优缺点

优点

• 快速发布：主干开发模型支持频繁的发布和交付，适合需要快速迭代和部署的项目。
• 降低合并冲突：开发人员频繁提交代码，有助于减少长时间不合并造成的冲突，也降低了代码合并的复杂度。
• 代码库简单：没有复杂的分支结构，便于维护和管理。
• 持续集成保障：与持续集成系统配合，可以有效地保障代码的稳定性，确保主分支在任意时刻都是可发布的。

缺点

• 功能隔离难度大：由于没有长期的功能分支，未完成的功能需要通过功能开关隔离，这对代码设计和管理提出了更高要求。
• 适应性问题：对依赖较多的复杂功能或有严格发布计划的大型项目来说，主干开发可能不适用。
• 严格的代码质量和测试要求：主干开发要求团队具备较高的代码质量标准和成熟的自动化测试流程，才能确保频繁合并不会影响主分支的稳定性。

主干开发模型适用的场景

主干开发模型特别适合持续交付和持续部署的项目场景，例如：

• 快速迭代的敏捷项目：需要频繁更新、快速发布和灵活响应的项目。
• 小型团队或初创项目：开发人员少、沟通成本低，主干开发可以提高协作效率。
• CI/CD成熟的团队：团队有完善的持续集成/持续部署流程，并具备稳定的自动化测试体系。

总结

主干开发模型是一种适合快速迭代、自动化集成的开发模式。通过精简分支结构和频繁合并，它为高频发布和协作提供了理想的方式。不过，这种模型对自动化测试和持续集成的依赖较高，适合拥有高质量交付体系和完善测试流程的团队。