主干开发与敏捷开发的匹配度
很多人在推行敏捷开发时会纠结：到底该用特性分支，还是坚持主干开发？主干开发指的是团队成员都直接在主干（main trunk）上提交代码，而不是拉出长长的特性分支。听起来有点冒险，但在节奏快、迭代频繁的敏捷环境中，它反而可能更合适。
敏捷的核心是快速反馈
敏捷不是简单地把任务拆小、开会站会，它的核心在于快速验证、快速调整。如果你的功能开发完要等两周才合并进主干，那这段时间里谁也不知道代码有没有冲突，业务逻辑会不会跑偏。等到集成那天，发现一堆问题，反而拖慢了节奏。
主干开发要求每天甚至每几小时就提交一次代码，配合自动化测试，能第一时间发现问题。比如你改了个用户登录逻辑，刚提交就被CI系统测出异常，立马就能修。这比堆在分支里最后“惊喜连连”强多了。
主干开发需要配套机制
当然，直接往主干上怼代码不等于瞎搞。没有规范和工具支持，主干很快就会变成“谁都不敢动”的雷区。
比如，团队得有足够覆盖率的单元测试和集成测试。每次提交自动触发流水线：
<pipeline>
<stage name="test">
<step command="npm run test:unit" />
<step command="npm run test:integration" />
</stage>
<stage name="deploy-to-staging" enabled="false" />
</pipeline>另外，功能开关（Feature Toggle）也很关键。新功能可以先提交到主干，但通过配置关闭，不影响线上使用。等产品确认 ready，后台一键打开，完全不用等发布窗口。
现实中的例子
我之前参与的一个电商项目，每周都要上线促销活动。早期用特性分支，每次合并都得三四个人通宵解决冲突。后来改成主干开发，配合自动化测试和功能开关，开发人员上午改完代码，下午就能看到效果，产品经理随时试用，提意见当天就能调。
变化最大的是心态——大家不再“藏代码”，而是争着早点提交，因为越早发现问题成本越低。主干不再是“危险区”，反而成了最稳定的代码源。
不是所有团队都适合
如果团队缺乏自动化测试，成员之间协作松散，或者代码质量参差不齐，贸然推主干开发可能会让主干天天红。这种情况下，先从短生命周期的特性分支过渡，逐步建立信心和流程更稳妥。
但如果你的团队已经习惯小步快跑，追求持续交付，主干开发反而是顺理成章的选择。它不是敏捷的标配，但确实是高成熟度敏捷团队的常见实践。