核心判断
分支管理的关键不是选择“分支”或“主干”本身，而是降低并行开发带来的认知负担与集成风险。多数企业采用分支开发，主干发布的发布流程和适用场景，但这种模式更接近认知行为模式中的 Complex 行为模式：它把问题拆到多个长期分支里处理，容易形成违反认知直觉的反模式。
更稳妥的演进路径是：先用主干开发结合特性短分支培养高频集成和高频发布的习惯，再逐步过渡到主干开发，主干发布的发布流程和适用场景。
这个主题下我目前知道的内容
三种典型发布流程
分支管理的实践原则
- 团队共享一条主干，避免长期并行主线。
- 特性分支的存活周期要尽量短，最好不超过 3 天。
- 每天至少向主干合并一次代码；如果特性分支存在超过 1 天，也要每天同步主干代码。
- 谨慎使用特性开关等技术手段，避免用工具掩盖流程复杂度，保持代码干净和历史清晰。
- 并行分支越少越好，能采用主干发布时尽量采用主干发布。
相关概念 / 下层卡片
- 主干开发，分支发布的发布流程和适用场景：主干负责日常集成，发布时从主干拉出发布分支。
- 分支开发，主干发布的发布流程和适用场景：多数企业常见模式，但容易累积长期分支与集成风险。
- 主干开发，主干发布的发布流程和适用场景：更符合高频集成与高频发布的目标状态。
- 长期分支会增加集成风险：解释为什么长期分支会把冲突、质量问题和业务偏差延迟到合并阶段集中爆发。
- 短生命周期特性分支降低认知负担：解释为什么短分支能减少团队同时维护的并行上下文。
- 认知行为模式：用于理解为什么复杂分支流程会增加团队的认知负担。
暂时结论
分支管理应优先围绕“减少长期并行、提高集成频率、降低认知负担”来设计。对多数团队来说，直接切到纯主干发布可能过于激进，更现实的路径是先缩短特性分支生命周期，再逐步减少发布分支和并行分支。