Workflows
长期分支冲突治理
把长期分支里的冲突处理从临时救火升级成可治理的流程，包括同步节奏、冲突热区识别和重复冲突复用。
- 要把命令组合成稳定流程的团队成员
- 需要处理协作顺序和分支边界的人
- 知道 fetch / pull / push / branch 的基本作用
- 能理解一条分支为什么会分叉
- 照抄流程却没确认当前分支关系
- 在共享分支上用错整合方式
为什么"冲突治理"值得单独成篇
长期分支同步主线频繁 rebase 产生相同冲突多个开发者修改同一区域
定期同步 → 减少冲突量识别热区 → 优先治理架构问题rerere → 自动复用解决方案
rerere (reuse recorded resolution) 记录冲突解决方案，下次遇到相同冲突自动应用。
很多团队处理冲突的方式是"等冲突来了再说"。
- 冲突反复出现
- 同一批文件总是高风险区
- 每次同步都像一次小型事故
所以你需要的不是一次次临时救火，而是一套长期治理思路。
更稳的治理思路
- 先固定同步节奏，减少大爆炸式整合
- 标记高频冲突文件和模块
- 用 rerere 复用重复冲突的解决方案
- 在团队里沉淀“哪些区域最容易打架”
为什么这比“等冲突来了再说”更有效
因为长期分支里的冲突，往往不是随机事件，而是可重复、可观察、可治理的问题。
很值得形成的习惯
- 每次同步后记录冲突热区
- 对重复冲突启用 rerere
- 一旦某些目录长期高冲突，回头讨论是不是应该拆模块、缩小并行修改范围
常见误区
- 以为冲突只是个人操作问题
- 每次同步都靠同一个人硬扛
- 看到 rerere 能复用，就不再检查结果
接下来建议继续学什么
rerere for recurring conflictslong-lived branch maintenanceshared-branch-sync-boundaries