如何优雅地解决Git合并冲突 (merge conflict)

Git 冲突
Git
文章字数:   1.7k
阅读时长:   6 分

好的，各位猿们，今天我们来聊一个每个程序员都会遇到的“坎”——Git 合并冲突（Merge Conflict）。

遇到这玩意儿，别慌，这很正常。就像开车上路，偶尔遇到堵车一样，它是版本控制协作中的一部分。今天，我就带你一步步优雅地解决它，让你从此不再“闻冲突色变”。

为什么会有合并冲突？

想象一下，你和你的同事小明都在各自的电脑上改同一个文件。

  • 你在第 10 行加了一句“Hello, Gemini!”。
  • 小明也在第 10 行加了一句“Hello, World!”。

当你们都想把自己的代码合并到主分支时，Git 就懵了：“第 10 行到底听谁的？” 这时候，合并冲突就产生了。

简单来说，冲突的原因就两点：

  1. 多个分支修改了同一个文件的同一块区域。
  2. 一个分支修改了文件，而另一个分支删除了这个文件。

Git 无法替你做决定，所以它会把这个“锅”甩给你，让你来当裁判。

发现并分析冲突

当你执行 git merge 或者 git pull 时，如果看到类似下面的提示，恭喜你，中奖了！

Auto-merging your-file.txt
CONFLICT (content): Merge conflict in your-file.txt
Automatic merge failed; fix conflicts and then commit the result.

这时候，先用 git status 看一下情况：

$ git status
On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   your-file.txt

no changes added to commit (use "git add" and/or "git commit -a")

Git 明确地告诉我们 your-file.txt 这个文件冲突了。

现在，我们打开这个文件，会看到类似下面的内容：

<<<<<<< HEAD
这里是你的修改内容
=======
这里是小明（或者其他分支）的修改内容
>>>>>>> feature-branch

Git 用 <<<<<<< HEAD、======= 和 >>>>>>> feature-branch 把冲突的部分标记了出来。

  • <<<<<<< HEAD 到 ======= 之间，是你当前分支（HEAD）的修改。
  • ======= 到 >>>>>>> feature-branch 之间，是你要合并进来的那个分支的修改。

手动解决冲突：最直接的方式

了解了冲突的“长相”，解决起来就简单了。

案例一：常规内容冲突

假设我们的 your-file.txt 冲突内容如下：

<<<<<<< HEAD
const greeting = "Hello, Gemini!";
=======
const greeting = "Hello, World!";
>>>>>>> feature-branch

解决方案：

你只需要编辑这个文件，决定最终要保留的内容。你有几个选择：

  1. 保留你的修改： 
    const greeting = "Hello, Gemini!";
  2. 保留小明的修改： 
    const greeting = "Hello, World!";
  3. 两个都保留，或者进行整合： 
    const greeting = "Hello, Gemini and World!";

决定好之后，**手动删除掉 Git 添加的那些标记符号 (<<<<<<<, =======, >>>>>>>)**，保存文件。

然后，按照 Git 的指示走完流程：

# 1. 将修改后的文件标记为已解决
git add your-file.txt

# 2. 提交这次合并
git commit -m "feat: 合并 feature-branch，解决冲突"

搞定！一次优雅的冲突解决就完成了。

案例二：一个分支删除，一个分支修改

如果小明删除了 your-file.txt，而你修改了它，git status 会是这样：

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)
        deleted by them:   your-file.txt

解决方案：

这时候你需要决定，这个文件到底还要不要。

  • 如果要保留文件（即保留你的修改）： 
    git add your-file.txt
  • 如果确认要删除文件（听小明的）： 
    git rm your-file.txt

选择一个操作执行后，再 git commit 即可。

使用图形化工具：更直观的选择

如果你觉得在命令行里看那些符号眼花缭乱，可以使用图形化的合并工具。

很多 IDE 都内置了强大的 Git 工具，比如 VS Code。当检测到冲突时，它会直接在文件上方提供选项：

  • Accept Current Change (接受当前更改)
  • Accept Incoming Change (接受传入的更改)
  • Accept Both Changes (接受双方的更改)
  • Compare Changes (比较差异)

你只需要点点鼠标，就可以轻松解决冲突，IDE 会自动帮你处理那些标记符号。

如果你想用独立的对比工具，比如 kdiff3、meld、p4merge 等，可以这样配置和使用：

# 1. 配置你喜欢的工具 (以 meld 为例)
git config --global merge.tool meld

# 2. 在遇到冲突时，启动工具
git mergetool

这会打开一个三栏对比视图，清晰地展示了“你的版本”、“共同祖先版本”和“他的版本”，以及一个最终的“合并结果”视图，让你进行编辑。

进阶技巧：git rerere

rerere 是 “reuse recorded resolution” (重用已记录的解决方案) 的缩写。 它可以记住你是如何解决一次冲突的，当下次遇到完全相同的冲突时，它会自动帮你解决。

这对于需要反复合并同一个长期开发分支的场景非常有用。

# 开启 rerere 功能
git config --global rerere.enabled true

开启后，你第一次手动解决完冲突并提交，Git 就会把解决方案记录下来。下次再遇到同样的冲突，你会看到一行提示 Resolved 'your-file.txt' using previous resolution.，Git 已经帮你搞定了！

如何从根源上避免冲突？

解决冲突虽然不难，但频繁解决也很烦人。下面是一些减少冲突的好习惯：

  1. 保持分支短小精悍：一个功能一个分支，尽快开发完并合并，不要让分支和主干偏离太远。
  2. 频繁更新主干代码：在开始新功能或提交代码前，先 git pull 或者 git fetch + git merge，确保你的代码基于最新的主干。
  3. 清晰的团队分工：尽量避免多个人同时修改同一个文件的核心部分。
  4. 有效沟通：在修改公共组件或核心逻辑前，和团队成员打个招呼。

紧急出口：搞砸了怎么办？

如果在解决冲突时，你把事情搞得一团糟，别担心，随时可以“反悔”。

git merge --abort

这个命令会立即停止这次合并，让你的代码库回到合并之前的状态，你可以冷静一下，重新再来。

总结

解决 Git 冲突是每个开发者的必备技能。记住这个流程：

  1. git status 查看冲突文件。
  2. 打开文件，手动编辑或使用图形工具解决。
  3. git add 标记已解决。
  4. git commit 完成合并。

希望这篇文章能让你在下次遇到 “CONFLICT” 时，能够淡定从容，优雅地解决问题。

Git 冲突
  目录