一次多人协作冲突后，我终于理解了 Git 分支和 PR 的真正作用
背景：一次“今天刚发生”的协作问题
这是我今天在实际项目协作中遇到并解决的问题。
当多人同时参与同一代码库开发时，冲突并不是偶发事件，而是必然事件。
真正的问题不在于“谁写得好不好”，而在于：系统是否具备处理冲突的能力。
1. 我们到底在解决什么问题？
在这次协作中，我意识到我们面对的并不是单一问题，而是三类冲突同时存在。
1.1 时间冲突（先后问题）
- 同一份代码
- 在不同时间
- 被不同人修改
冲突的根源并不是能力问题，而是时间错位。
1.2 认知冲突（谁对谁错）
- 你觉得这样对
- 别人觉得那样对
在当下阶段，很难立刻分出“绝对正确”。
1.3 稳定性冲突（现在能不能用）
- 新功能 ≠ 稳定
- 稳定 ≠ 最新
系统不可能同时满足所有目标，必须做出取舍。
2. 分支的本质：不是管理代码，而是管理风险
分支存在的意义，并不是为了“流程更复杂”，
而是为了在协作中隔离风险。
不同分支，本质上代表了不同的风险承受等级。
3. 三种分支 = 三种风险区
main：零容忍风险区
任何时候都必须：
- 能跑
- 能交付
- 不解释
这是成品区。
develop：可控风险区
允许：
- 新功能
- 小 Bug
但必须：
- 不影响整体运行
这是半成品装配线。
feature：高风险实验区
允许：
- 报错
- 推翻重写
- 临时 hack
这是个人试验台。
4. PR（Pull Request）的底层逻辑
把「我觉得可以」变成「我们都看过了」。
PR 的作用不是评判“谁写得好”，
而是完成一次关键转变：
把个人判断，升级为团队共识。
在 PR 之前，风险只由个人承担；
在 PR 之后，风险进入团队可控范围。
5. 总结：工程机制是在对抗协作中的不确定性
这次经历让我真正意识到：
- 分支不是形式
- PR 不是走流程
- 它们的存在，是为了让协作可持续发生
当系统规模变大时，你不可能依赖“大家都谨慎一点”来维持稳定。
工程机制的意义，在于把不确定性限制在可接受范围内。