什么是主干开发
主干开发（Trunk-Based Development）是一种常见的软件开发模式，核心理念是所有开发者都在一个共享的主干分支（通常是 main 或 trunk）上进行提交，而不是长期维护多个功能分支。这种方式听起来简单，但在实际项目中能显著提升协作效率。
比如你和同事一起开发一个电商后台系统，大家每天都在同一个主干上提交代码。每次改动都小而快，避免了“我写了一个月的功能，合并时冲突一堆”的尴尬场景。
实际工作中的使用场景
我们团队去年接手一个订单管理模块重构任务。起初采用的是功能分支模式，每个人拉一个 feature/order-refactor-xxx 分支，结果到集成阶段花了一周时间解决冲突，还引入了好几个隐藏 bug。
后来改用主干开发，要求所有人每天提交的代码不超过一天工作量，且必须通过自动化测试。每次提交都是可运行的状态，哪怕功能还没做完，也会用开关（Feature Flag）控制是否启用。这样一来，集成不再是个“大事件”，而是日常操作。
如何配合工具落地
主干开发不是光靠约定就能跑起来的，得有配套机制。我们用了 GitLab + CI/CD 流水线，只要推送到主干，自动触发单元测试、代码扫描和部署到预发环境。
举个例子，当你提交一段处理支付回调的代码，CI 系统会在几分钟内告诉你是否通过测试：
git add .
git commit -m "fix: handle timeout in payment callback"
git push origin main如果测试挂了，系统会立刻通知你，不能让问题留在主干里。这种快速反馈就像做饭时尝一口咸淡，随时调整，不至于整锅做完才发现太咸。
小步提交是关键
主干开发最怕“巨无霸提交”。曾经有个同事一次性提交了 2000 行代码，结果把日志格式全改了，影响了其他模块的监控报警。后来我们规定单次提交不超过 300 行，超过就得拆开。
就像你写文章，一口气写完十页容易出错，不如写一段检查一段。代码也一样，小步快跑才稳。
适合哪些团队
主干开发对团队协作要求高，适合节奏快、有自动化保障的小型到中型团队。如果你公司还在用“每周合一次代码”这种模式，可能需要先补上自动化测试这一课。
但一旦跑顺了，你会发现：发布不再提心吊胆，新人也能快速上手，主干始终是可用状态。这不就是我们想要的开发体验吗？