1. 概述
本文将介绍版本控制系统（VCS）中一种重要的开发实践方式：Trunk-Based Development（基于主干的开发）。
我们将从 Trunk-Based Development 的基本概念讲起，分析它与常见的 Feature Branch 模式之间的区别，以及它所具备的核心特征和典型工作流程。
接着，我们会讨论采用 Trunk-Based Development 时需要考虑的一些关键因素，并总结其优缺点。
2. 什么是 Trunk-Based Development？
Trunk-Based Development 是一种源码控制分支模型，开发者在一条主分支（如 Git 中的 main 或 master）上进行开发。
这种模式不依赖长期存在的开发分支，因此能有效减少合并冲突，避免频繁破坏构建。
在 Trunk-Based Development 中，团队成员主要围绕 trunk 分支进行协作。对于较大团队，可能会使用一些短生命周期的分支，但通常不会超过几天。
开发者频繁提交代码到 trunk，每次提交都会触发自动化测试流程，从而在早期发现集成问题。
这种模式鼓励持续集成（CI），非常适合敏捷小团队使用。
3. 与 Feature Branch 模型的对比
Feature Branch 是目前团队中最为常见的一种开发方式。在这种模式下，开发者从主分支拉出独立的长期分支，用于开发新功能或改进，完成后才合并回主分支。
这种方式的优点在于允许开发者独立开发，互不影响，特别适合多人协作、代码结构复杂的大型项目。
相比之下，Trunk-Based Development 更强调频繁集成、快速反馈和团队协作。
4. Trunk-Based Development 的核心特征
Trunk-Based Development 有以下几个关键特征，这些特征决定了团队协作和开发效率的上限：
4.1. 持续集成（CI）
所有开发者都在同一个主分支上工作，使得代码集成更加频繁和高效，从而显著减少合并冲突。
✅ 鼓励开发者尽可能频繁地提交代码变更，而不是积攒大量修改一次性提交。
4.2. 小粒度、高频提交
频繁提交小粒度变更，可以避免后期出现大规模合并的问题。
这不仅降低了合并复杂度，也更容易发现和解决冲突。而且由于提交频繁，引入 bug 的概率也更小。
4.3. 自动化测试
自动化测试是 Trunk-Based Development 的基石。由于频繁提交，必须确保每次提交后构建不会失败，也不会引入回归问题。
✅ 提高测试覆盖率，有助于减少回归风险，加快问题修复速度。
✅ 自动化测试提供即时反馈，提升整体代码质量。
4.4. 代码评审（Code Review）
每次提交前，都需要经过其他开发者的评审和反馈，以提升代码质量并提前发现潜在问题。
⚠️ 评审流程应设定合理时限，避免影响提交节奏。
4.5. 避免长期分支
任何超过两天的分支都有可能演变为长期分支。Trunk-Based Development 明确避免长期分支，以减少合并冲突，提升集成效率。
5. 工作流程详解
Trunk-Based Development 的典型流程包括以下几个关键步骤：
5.1. 编写并提交代码
开发者在完成本地开发后，直接提交到 trunk 或一个短生命周期的分支。
✅ 建议遵循“每天至少提交一次”的原则，确保本地代码不会滞留太久。
5.2. 创建 Pull Request
提交完成后，开发者立即创建 Pull Request，请求将变更合并到主分支。
Pull Request 中应包含变更描述、修改内容、相关上下文等信息。
5.3. 代码评审
其他开发者对 Pull Request 中的变更进行评审，识别潜在问题或改进点。
✅ 评审过程可帮助新人快速掌握项目规范，同时提高整体代码质量。
5.4. 自动化测试执行
提交后会自动触发单元测试和集成测试。
✅ 自动化测试确保新代码不会破坏现有功能，为开发者提供信心保障。
5.5. 合并代码
通过评审和测试后，代码即可合并到 trunk。
由于提交频率高、分支生命周期短，大大降低了合并冲突的可能性。
6. 选择 Trunk-Based Development 的考量因素
是否采用 Trunk-Based Development，取决于多个因素，包括项目复杂度、开发流程、团队规模等。
6.1. 优点
- ✅ 高效快速集成：单一分支、高频提交，减少合并冲突，提升集成效率。
- ✅ 代码更稳定：频繁提交有助于早期发现问题，避免大规模合并带来的风险。
- ✅ 促进团队协作：所有人在同一分支上工作，更容易了解彼此的改动，提升协作效率。
- ✅ 支持持续交付（CI/CD）：主分支始终处于可部署状态，便于快速交付新功能。
- ✅ 减少技术债务：通过频繁合并和小粒度提交，避免“大合并”带来的技术债积累。
6.2. 缺点
- ❌ 构建风险较高：由于提交频繁，一旦测试不完善，可能破坏构建，影响其他开发者。
- ❌ 变更隔离困难：多个变更可能混在一起提交，难以单独测试和回滚。
- ❌ 发布管理复杂：如果需要中间版本发布，Trunk 中可能混杂未完成的功能，管理难度增加。
- ❌ 团队规模限制：人数较多时，协调成本高，流程不清可能导致效率下降。
7. 总结
Trunk-Based Development 是一种强调持续集成、团队协作和高效交付的开发实践。
本文介绍了它的核心概念、工作流程、与 Feature Branch 的区别，以及其优缺点。
✅ 对于希望提升开发效率、加强团队协作、降低技术债务的团队，Trunk-Based Development 是一个值得尝试的开发模式。