原文链接：
主干开发的重点是让团队围绕一条主要代码线持续集成，尽量减少长期分支。
它背后的判断是：分支存在越久，集成风险越大，反馈越晚，冲突和语义偏差越难处理。
大规模团队采用主干开发，核心原因是它把复杂度提前暴露到每天的集成、测试和评审中。
| 前提 | 说明 |
|---|---|
| 快速 CI | 变更合入前后都要尽快反馈 |
| 小变更 | 每个提交和 PR 都要足够小，便于 Review 和回滚 |
| 代码所有权 | 关键路径要有人负责审查 |
| 自动化测试 | 主干稳定依赖可靠测试信号 |
| feature flag | 未完成能力不能直接暴露给用户 |
| 快速回滚 | 主干出现问题后要能快速撤销 |
没有这些前提，主干开发会变成“大家直接往主分支堆代码”。
主干开发并不等于完全没有分支。
更现实的做法是：
short-lived branch -> review -> main -> CI -> release
长期分支把风险推迟到合并那一天。
主干开发把风险拆成很多小块，在每天的提交和检查中处理。
主线越接近线上，问题定位越简单。
当线上版本可以追溯到主线上的清晰 commit 或 tag，回滚和审计都更容易。
CI、代码搜索、依赖分析、代码所有权、发布系统，都可以围绕主线建立统一模型。
多条长期分支会让这些能力的复杂度快速上升。
不要一上来追求“纯主干开发”。
更稳的顺序是：
适合：
不适合：
主干开发不是一种轻流程口号，它是一组工程能力的结果。
如果团队想用它，需要同时建设：
这些能力比“是否只保留一个主分支”更重要。