Git TBD（Trunk Based Development） 主干开发模型

Git TBD

Git工作流中的TBD（Trunk-based Development）是一种基于主干分支的开发模式，其核心思想是所有团队成员都在单个主干分支（通常是master分支）上进行开发。这种工作流模式简化了开发流程，减少了分支切换的复杂性，并提高了持续集成的效率。以下是对TBD工作流的详细解析：

一、TBD工作流的特点

• 单一主干分支：所有开发活动都在主干分支上进行，避免了多个长期分支带来的管理复杂性。
• 快速集成：由于所有开发都在主干上进行，因此可以更快地实现代码集成，减少合并冲突。
• 持续集成：支持持续集成和持续部署（CI/CD），确保代码质量和稳定性。
• 简化流程：减少了分支创建、合并和删除的操作，简化了开发流程。

二、TBD工作流的实践

• 开发：团队成员在主干分支上直接进行开发，提交代码变更。
• 测试：通过自动化测试工具对代码进行持续测试，确保代码质量。
• 发布：当需要发布新版本时，可以使用标签（tag）来标记特定的提交作为发布版本。如果需要进行更复杂的发布管理，可以从主干分支创建发布分支，但这种情况相对较少。
• 修复：对于发现的bug，直接在主干分支上进行修复，并通过自动化测试验证修复效果。

三、TBD工作流的适用场景

TBD工作流适用于以下场景：

• 团队规模较小，成员之间沟通顺畅。
• 项目周期较短，需求变更不频繁。
• 追求快速迭代和持续集成的项目。

四、TBD工作流的优缺点

优点：

• 简化开发流程，减少分支管理复杂性。
• 提高持续集成效率，加快代码集成速度。
• 便于团队成员之间的协作和沟通。

缺点：

• 对于大型项目或复杂项目，可能难以在单个主干分支上管理所有开发活动。
• 如果团队成员之间的协作不够紧密，可能会导致代码冲突和集成问题。

五、总结

TBD工作流是一种高效、简洁的Git工作流模式，适用于追求快速迭代和持续集成的项目。通过减少分支切换和合并的复杂性，它提高了开发效率和代码质量。然而，在选择使用TBD工作流时，需要根据项目实际情况和团队规模进行综合考虑。

注意

使用主干开发后，我们的代码库原则上就只能有一个 Trunk 分支即 master 分支了，所有新功能的提交也都提交到 master 分支上，保证每次提交后 master 分支都是可随时发布的状态。没有了分支的代码隔离，测试和解决冲突都变得简单，持续集成也变得稳定了许多，但也有如下几个问题：

1. 如何避免发布引入未完成 Feature，答案是使用 Feature Toggle 。
   • 在代码库里加一个特性开关来随时打开和关闭新特性是最容易想到的也是最容易被质疑的解决方案。Feature Toggle 是有成本的，不管是在加 Toggle 时的代码设计，还是在移除 Toggle 时的人力成本和风险，都是需要和它带来的价值进行衡量的。
2. 如何进行线上 Bug Fix，答案是在发布时打上 Release Tag，一旦发现这个版本有问题，如果此时 master 分支还没有其他提交，那可以直接在 master 分支上 Hot Fix 然后合并至 release 分支；如果 master 分支已经有了提交就需要做以下三件事：
   1. 从 Release Tag 创建发布分支。
   2. 在 master 上做 Fix Bug 提交。
   3. 将 Fix Bug 提交 Cherry Pick 到 release 分支。
   4. 为 release 分支打上新的 Tag 并做一次发布。