一句话定义：主干开发（Trunk-Based Development）是一种代码分支策略，即所有人——包括写代码的智能体——都频繁地把很小的改动合入同一条主干（trunk，通常就是 main），而不是各自拉长期分支各干各的；某个功能是否上线，由特性开关（Feature Flag）控制，而不是由“分支有没有合并”决定。
为什么这么做：长期分支最大的敌人是合并冲突。打个比方：一份 PPT 如果每个人拷走改一个月再交回来，合并时必然面目全非；主干开发是大家在同一份在线文档上改，每次只改一小段，改完立刻提交。冲突没消失，但被切成了每天几十个小冲突，随手就能解掉。
代价是它对工程基建要求很高，通常配套四件事：
| 配套机制 | 作用 |
|---|---|
| 小批量提交 | 一次改动几百行以内，分支活几小时到一两天 |
| 持续集成（Continuous Integration, CI） | 合入即自动构建测试，坏了当场修或回滚 |
| 特性开关 | 代码合进去但默认关闭，上不上线由开关决定 |
| 合并队列（Merge Queue） | 多个改动排队串行验证，避免互相踩踏 |
和相邻概念的区别：Git Flow 保留 develop、release、hotfix 等长期分支，发布节奏重；GitHub Flow 是“短分支 + 拉取请求（Pull Request, PR）评审 + 合并”，本质仍是分支合并驱动发布。主干开发把分支寿命压到极短，甚至直接推主干配合代码评审，发布与合并彻底解耦——功能代码可以先躺在 main 上，开关一开才算上线。
智能体加入后，冲突模式变了：人一天提交几次，冲突窗口小；智能体可以并行开十几个 PR，每个都基于几分钟前的 main，而且它们偏爱改同一批“公共设施”——路由表、配置文件、类型定义、依赖清单。于是冲突从“文本冲突”变成“语义冲突”：Git 显示无冲突合并成功，但两个开关互相覆盖、两个智能体各自写了一个同名工具函数、两份迁移脚本顺序颠倒。主干开发会把这个矛盾放大，因为所有智能体都挤在同一条主干上，谁合得慢，谁就得重新跑一遍验证。实践上要靠更细的改动拆分、按目录划分所有权、严格的命名规范，以及把合并队列当作关键基础设施来建设。评审带宽往往比生成代码的速度更早成为瓶颈。
对从业者的意义：CI 跑得多快，交付就能多快；会写测试、会把改动切小、会给开关起规范名字，是主干开发的基本功。对普通人的意义：你手机 App 里的新功能，很多早就随版本装好了，只是开关没打开——所以产品能“一键上线、一键关停”，而不必等你更新版本。具体工具的配置细节，以官方页面为准。