Git 合并冲突别瞎改！这才是正确的处理流程

合并冲突不可怕，可怕的是你不知道自己在解决冲突的时候把别人的代码删了。

---

合并冲突是 Git 使用中最让新手崩溃的事情。

我带过的实习生里，有人遇到冲突直接全选自己的代码、丢掉别人的改动。有人干脆 git merge --abort 逃跑，然后另起分支重新写。

都不是正解。

今天把合并冲突的前因后果、具体操作、常见坑点一次性讲透。

---

为什么会冲突？

一句话：两个人改了同一个文件的同一行。

            main 分支       你的分支
               │               │
第 10 行    price = 99      price = 199

Git 不知道该保留 99 还是 199，所以它停下来让你手动决定。

不会冲突的情况： 两个人改了同一个文件的不同位置——Git 能自动合并。

---

冲突长什么样？

git merge 或 git pull 之后，如果有冲突，文件里会出现这样的标记：

<<<<<<< HEAD
price = 99
=======
price = 199
>>>>>>> feature/update-price

标记	意思
<<<<<<< HEAD	这一段是当前分支的代码
=======	分隔线
>>>>>>> feature/xxx	这一段是要合并进来的分支的代码

你要做的：删掉标记，保留正确的代码。

---

正确的处理流程（逐步操作）

第 1 步：看看哪些文件冲突了

git status
# 冲突的文件会显示 "both modified"

第 2 步：打开冲突文件，理解两边的改动

在改之前，先搞清楚两件事：

1. HEAD（当前分支）的改动是什么意图？
2. 对方分支的改动是什么意图？

别着急删代码——先读懂再动手。

第 3 步：解决冲突（三种情况）

情况	你该怎么做	举例
只保留自己的	删掉对方的代码和所有标记	对方的改动已经废弃了
只保留对方的	删掉自己的代码和所有标记	你的改动不再需要了
两边都要	手动合并两段代码，删掉标记	最常见的情况

举个"两边都要"的例子：

// 冲突前
<<<<<<< HEAD
const price = 99;
const currency = 'CNY';
=======
const price = 199;
const discount = 0.8;
>>>>>>> feature/update-price

// 正确解决后
const price = 199;          // 用对方的新价格
const currency = 'CNY';     // 保留自己加的币种
const discount = 0.8;       // 保留对方加的折扣

第 4 步：标记冲突已解决

# 告诉 Git："我处理好了"
git add <冲突文件>

# 如果是 merge 冲突，继续完成合并
git commit

# 如果是 rebase 冲突，继续 rebase
git rebase --continue

---

用 VS Code 解决冲突（更直观）

VS Code 遇到冲突文件会自动高亮，并且给你 4 个按钮：

按钮	效果
Accept Current Change	保留当前分支（HEAD）的代码
Accept Incoming Change	保留对方分支的代码
Accept Both Changes	两段都保留（上下拼接）
Compare Changes	打开对比视图，左右比较

我的习惯：先点 “Compare Changes” 看清楚两边改了什么，再决定怎么合。

---

高频踩坑场景

坑 1：git pull 的时候突然冲突了

原因：git pull = git fetch + git merge。远程有人改了你也改了的文件。

预防：养成习惯，每天开工前先 git pull。改动越少，冲突越小。

坑 2：解决完冲突，发现把别人的代码删了

补救：

# 查看合并前对方分支的代码
git show feature/xxx:path/to/file

# 或者直接回滚这次合并
git merge --abort    # 如果还没 commit
git revert -m 1 HEAD # 如果已经 commit 了

预防：解决冲突之后，一定要 git diff 看一眼改了什么再 commit。

坑 3：Rebase 冲突一个接一个

原因：rebase 是逐个提交重放的。如果你有 10 个 commit 都改了同一个文件，可能要解决 10 次冲突。

处理：

# 如果冲突太多太乱，放弃 rebase
git rebase --abort

# 改用 merge（只需要解决一次冲突）
git merge main

什么时候用 rebase、什么时候用 merge？

场景	推荐	原因
分支提交很少（1-3 个）	rebase	历史更干净
分支提交很多、改动很大	merge	一次性解决冲突
已经 push 到远程的分支	merge	rebase 会改写历史，影响别人
自己本地还没 push	rebase	安全，不影响别人

坑 4：合并完了才发现合错了

# 如果还没 push
git reset --hard HEAD~1

# 如果已经 push 了
git revert -m 1 <合并的commit哈希>

---

一条黄金法则

解决冲突的时候，永远不要只看代码表面——要理解每一方改动的意图。

两个人改了同一行，不代表只能留一个。很可能两边的改动都需要保留，只是需要你把它们合理地融合在一起。

如果你实在不确定对方的代码是什么用意——去问他。这比你猜着改然后上线出 bug 好一万倍。

---

点赞 👍 + 收藏 ⭐ 备用。如果你的团队也总被合并冲突折腾，转给他们看看。

标签：#Git #合并冲突 #版本控制 #踩坑记录 #团队协作 #开发技巧