Git冲突解决指南：从“救命啊“到“就这？“的蜕变之路

一、Git冲突的"前世今生"（必看！）

各位老铁们（敲黑板），咱们今天要聊的这个Git冲突啊，就像程序员的青春痘——早晚都得长！但别慌，等你看完这篇指南，绝对能从容应对各种幺蛾子。

1.1 冲突的"诞生仪式"

当两个开发者在不同分支修改同一文件的同一位置时，Git就懵圈了（内心OS：你们人类怎么这样？！）这时候它会抛出经典三连：

CONFLICT (content): Merge conflict in [文件名]
Auto-merging failed...

1.2 冲突的"爆炸现场"

打开冲突文件你会看到这样的"车祸现场"：

<<<<<<< HEAD
你的代码
=======
别人的代码
>>>>>>> branch_name

这个符号大礼包的意思是：老兄，你自己选吧，我不管了！

二、手把手教你解决冲突（实战！）

2.1 解决四步曲

1. 拉取最新代码（重要指数⭐⭐⭐⭐⭐）

   git fetch origin
   git rebase origin/main
   

   （注意！用pull可能引发更多问题，后面会讲）

2. 定位冲突文件

   git status
   

   红彤彤的"both modified"就是我们的目标

3. 人工裁决
   用编辑器打开文件，三选一：

   • 保留自己的（删掉别人的部分）
   • 保留别人的（删掉自己的部分）
   • 都要！（手动整合）

4. 完成合并

   git add [解决后的文件]
   git rebase --continue
   

2.2 超实用工具推荐

• VS Code的GitLens插件（冲突可视化神器！）
• Meld（三窗格对比工具，拯救密集恐惧症）
• IntelliJ的Merge Tool（Java党的福音）

三、高阶操作手册（进阶必读！）

3.1 冲突预防大法

• 小步提交：每次提交的粒度要细（别攒大招！）
• 规范分支策略：推荐Git Flow工作流
• 预合并测试：在本地先试着重演别人的修改

3.2 骚操作预警

当遇到史诗级冲突时：

# 放弃当前修改（慎用！）
git merge --abort

# 暴力解决法（适合简单项目）
git checkout --ours [文件]
git checkout --theirs [文件]

四、血泪教训总结（不看后悔！）

4.1 新人常见作死操作

1. 在冲突文件里保留<<<<<<<符号（直接GG）
2. 忘记add修改就continue（陷入无限循环）
3. 用pull代替fetch+rebase（可能引发提交历史混乱）

4.2 我的翻车实录

去年有个项目，我和老王同时修改了配置文件。当时为了省事直接用了–theirs，结果把线上配置覆盖了…（服务器当场去世！）血泪教训：解决完冲突一定要跑测试！

五、终极解决方案（压箱底干货！）

5.1 配置.gitattributes

在项目根目录创建这个文件，指定合并策略：

*.json merge=union
*.config merge=ours

（这样Git就会自动合并某些文件类型啦！）

5.2 使用rerere功能

开启Git的"记住我的选择"模式：

git config --global rerere.enabled true

（适合长期维护的分支，能自动复用之前的解决方案）

六、灵魂拷问环节

Q：为什么我解决完冲突后git status还是显示有修改？
A：八成是忘记add修改后的文件啦！（快回去看第2章！）

Q：rebase和merge到底用哪个？
A：个人开发用rebase保持线性历史，团队协作用merge保留完整记录（划重点！）

Q：冲突太多想跑路怎么办？
A：试试git reset --hard origin/main（但会丢失本地修改！三思啊！）

最后送大家一句真言：早提交，勤合并，多沟通。Git冲突就像感情问题，预防永远比解决更重要！遇到问题别怂，多试几次你就是merge大师！（拍肩）