Git合并冲突：不再头疼

不知道你有没有遇到过这种情况：早上打开电脑，pull 最新代码，结果弹出满满一屏的 CONFLICT，当时的心情就像过山车一样从山顶跌到谷底。我也不例外，刚工作那会儿，每次遇到合并冲突都手忙脚乱，要么强行 commit 导致代码丢失，要么找同事帮忙结果越帮越乱。

今天这篇文章，就是把我这些年处理合并冲突的经验整理成 5 个实用技巧，保证你看完之后再也不会对冲突“谈虎色变”。

1. 合并前先“偷看”一眼

很多冲突其实是可以预防的。在执行 git merge 或 git pull 之前，先用 git fetch 拉取最新代码，然后用 git diff 看看自己和远程分支到底有哪些文件修改了。

# 先拉取但不合并
git fetch origin

# 查看与远程分支的差异
git diff HEAD origin/your-branch --stat

这个习惯让我至少避免了 30% 的意外冲突。很多时候，你只需要在合并前和同事简单沟通一下，确定谁负责哪个文件的修改，冲突自然就少了。

2. 善用可视化工具

说实话，我以前一直坚持用命令行，觉得这才够“硬核”。但自从用了可视化工具处理冲突，效率至少提升了一倍。

VS Code 内置的合并冲突编辑器就很不错，冲突文件会用三种颜色清晰标记：当前更改、传入更改、两者都有。你只需要点击“接受当前更改”“接受传入更改”或者手动编辑就可以了。

如果你想要更专业的工具，我推荐 GitKraken 或 SourceTree。它们能图形化展示分支走向，冲突处理起来更加直观。特别是当一个文件有多个冲突时，可视化工具能帮你一目了然地看到全局。

3. 学会“拆解”复杂冲突

有时候合并会涉及几十个文件、几百处冲突，这时候千万别硬着头皮一次性解决。我的经验是“分而治之”：

# 查看冲突文件列表
git diff --name-only --diff-filter=U

# 逐个解决，先从最简单的开始
# 每解决一个，就标记为已解决
git add resolved-file.js

为什么建议从最简单的开始？因为解决冲突是个“手感”问题。一开始你可能还不熟悉项目的代码结构，先搞定几个简单的能帮你热热身，找找感觉。后面处理复杂冲突时效率反而更高。

4. 用 git checkout –ours/theirs 做选择题

如果你确定某一方的修改完全正确，不需要“融合”，可以直接选用某一侧的版本：

# 接受自己这一侧的版本
git checkout --ours conflict-file.js

# 接受对方（远程）的版本
git checkout --theirs conflict-file.js

不过这个命令要慎用。我一般只在以下两种情况使用：一是明确知道某一方的修改是错误的；二是冲突文件是配置文件，比如 package-lock.json 这种自动生成的文件。

5. 预防永远好过处理

最后一点，也是最重要的：养成良好的 Git 使用习惯，尽量减少冲突的发生。

小步提交：与其一次性提交几百行修改，不如分成多个小提交。每个提交只改一件事，这样合并时即使有冲突，影响范围也很小。

及时同步：每天上班第一件事 git pull，下班前 git push。别等到周五下班前一次性提交一周的代码，那时候不冲突才怪。

功能分支：每个需求、每个 bug 都用独立的分支开发。主分支保持稳定，冲突自然就少了。

小结

合并冲突是每个开发者逃不过的坎，但只要你掌握了正确的方法和工具，完全可以从“恐惧冲突”变成“从容应对”。

记住这五点：合并前先 diff、用好可视化工具、拆解复杂冲突、灵活选用版本、最后养成好习惯。做到了这些，下次再遇到 CONFLICT，你完全可以淡定点一杯咖啡，然后优雅地解决它。

毕竟，会处理冲突的开发者，才是真正成熟的开发者。