Git 版本控制与跨平台协作
10.8 冲突解决实战
Tip
冲突不是错误，冲突是 Git 在说："我不知道该听谁的，请人类来做主。"
1. 为什么要学这个?
没有 Git 的时代是黑暗的。
在 Dropbox 共享文件夹时代，你和同事同时打开了 index.html。
你改了标题，保存。
他改了页脚，保存。
结果：谁后保存，谁就赢了。你的修改被无声无息地覆盖了。
Git 的冲突 (Conflict) 其实是一种保护机制。它宁愿停下来报错，也绝不瞎猜，绝不让任何一行代码被"静默吞噬"。
2. 核心概念：手术现场
当 Git 告诉你 MERGE CONFLICT 时，它会把两份代码同时塞进文件里，并用尖括号标记出来。
这就好比两辆车挤进了一个车道，Git 把现场封锁了，等你来交警判责。
识别伤口
打开冲突文件，你会看到：
<<<<<<< HEAD
const title = "Hello World"; // 你的代码 (Current Change)
=======
const title = "Hi World"; // 队友的代码 (Incoming Change)
>>>>>>> feature/new-ui
<<<<<<<: 冲突开始。=======: 分界线。>>>>>>>: 冲突结束。
3. 解决方案 (HOW)
AI 时代的解法 (Vibe Coding)
不要手动去删那些尖括号，容易删坏结构（比如少删了一个括号）。 直接把这段带标记的代码发给 AI。 Prompt:
"解决这个 Git 冲突。保留 Current Change 的文案，但保留 Incoming Change 的样式。请给我修复后的完整代码。"
手动解法 (VS Code)
VS Code 会在冲突上方贴心地显示四个按钮：
- Accept Current Change (保留我的): "队友写的是垃圾，听我的。"
- Accept Incoming Change (保留传入): "我写错了，听队友的。"
- Accept Both Changes (都保留): "我全都要 (通常需要手动调整顺序)。"
解决后的必做动作
解决完冲突后，文件还在"红色"状态。必须执行：
# 1. 告诉 Git 伤口处理好了
git add .
# 2. 提交缝合手续
git commit -m "fix conflict"
流程图
graph TD
Pull["git pull / merge"] --> Conflict{"冲突发生"}
Conflict -- No --> Success["自动合并"]
Conflict -- Yes --> State["进入 (MERGING) 状态"]
State --> Mark["文件生成 <<<< ==== >>>>"]
Mark --> Human["人工/AI 介入决策"]
Human -->|Accept| Resolve["代码恢复正常"]
Resolve --> Add["git add (标记已解决)"]
Add --> Commit["git commit (完成合并)"]
Commit --> Success
style State fill:#ffcdd2,stroke:#c62828
style Human fill:#fff9c4,stroke:#fbc02d
4. 真实案例
Story
那个被"Accept Yours"删掉的路由
某新手在解决 app.json 冲突时，因为看不太懂队友加了什么配置，心想"反正我的代码是对的"，于是一路狂点 "Accept Current Change"。
后果：
他保留了自己的代码，但把队友刚加的 5 个新页面的路由配置全删了。
上线后，新功能点击全部 404。
Vibe 心法： 冲突是协作中的灵魂博弈。 每一个冲突背后，都是两个思想的碰撞。 不要盲目点击按钮。看不懂队友的代码时，站起来，走到他座位旁边，问一句："哥们，这块我们要怎么留？"
5. 本章小结
- 别慌：看到冲突说明 Git 在保护你。
- 别盲目：不要无脑选"Current"，也不要无脑选"Incoming"。
- 别忘了 Commit：解完冲突不 Commit，你的仓库会一直卡在 MERGING 状态。