什么是主干开发
主干开发（Trunk-Based Development）是一种源代码管理策略，开发者在同一个主分支（trunk 或 main）上频繁提交代码，通常配合短周期发布和自动化测试。这种方式不像 Git Flow 那样维护多个长期分支，而是强调小步快跑、持续集成。
比如你在一个电商团队做前端开发，每天要上线几个小功能，像“购物车加购提示”、“优惠券弹窗优化”。如果每个功能都拉一个独立分支，一个月下来可能有几十个分支，合并冲突频发，上线前还要花三天时间整合，效率很低。而采用主干开发，大家都在 main 分支提交，每次改一点点，通过特性开关控制是否启用，问题就少了。
实际项目中的应用
某金融科技公司在推进支付系统升级时采用了主干开发。他们把大需求拆成多个小任务，每个任务不超过两天完成。所有代码直接提交到 main 分支，但通过 CI 流水线自动运行单元测试、代码扫描和集成测试。
例如新增“指纹支付”功能时，并没有单独建 feature/fingerprint-pay 分支，而是在 main 上直接开发。关键代码用特性开关包裹：
<?php
if (FeatureToggle::isEnabled('fingerprint_payment')) {
echo $this->renderFingerprintButton();
}
?>这样代码虽然合入了主干，但普通用户看不到，只有内部测试人员开启开关后才能使用。等整体稳定后再关闭开关，实现灰度上线。
遇到的问题与应对
刚开始推行时，团队不习惯频繁提交。有人写了一周代码才 push 一次，结果和其他人冲突严重。后来规定每天至少 commit 两次，且每次提交不能破坏构建。
另一个问题是多人同时改同一文件。比如两个后端同事都在调整订单状态机逻辑，容易覆盖对方修改。解决方案是加强沟通，使用代码评审（PR）机制，哪怕只改一行也要发起 review，确保透明。
他们还引入了“守护分支”策略：main 分支设为受保护分支，禁止强制推送，必须通过 CI 全部检查才能合并。这避免了人为失误导致主干不可用。
与传统分支模型的对比
以前用 Git Flow，每上线一个版本要维护 develop、release、hotfix 多个分支。一次紧急修复要先改 hotfix，再合并回 develop 和 main，流程繁琐。主干开发简化了这个过程——发现问题直接在 main 上修复，几分钟内就能部署。
当然也不是所有场景都适合。大型重构或实验性功能仍建议用短期分支，控制在一天内完成并合并，避免长时间脱离主干。
现在很多互联网公司如 Netflix、Google 都采用类似模式，核心就是“早集成、常集成”，把集成风险分散到每一天，而不是堆到期末集中处理。