2. 冲突到底是怎么来的2.1 冲突不是错误而是一道保护机制先说一个可能颠覆很多人认知的观点Git 冲突并不是“坏事”更不是“代码被弄坏了”。我见过不少新人一看到 CONFLICT 字样就慌以为整个仓库要重来其实完全不是这样。冲突恰恰说明 Git 在执行一次“负责任的合并”——它发现两个分支在同一位置做了不同修改而它自己又没有上帝视角不知道你们俩谁才是对的于是停下来把你叫过来当裁判。Git 不是改不了而是不敢瞎改。这就像两个人同时改同一份 Word 文档的同一段文字提交的时候 Word 不可能自动判断该保留谁的版本只能列出两个版本让你来拍板。Git 冲突的本质就是“合并过程中两个分支对同一块内容产生了分歧Git 需要人类介入裁决”。搞清楚这一点心态上就先稳了。你不会因为冲突丢掉代码两个版本的改动其实都还在你的任务不过是从中挑出一个正确组合甚至按需把两边的内容都保留下来。2.2 合并到底在比什么三方对比模型要真正理解冲突我建议你先忘掉“冲突”这个字眼把一个核心姿势刻在脑子里Git 合并merge永远是一次三方对比three-way merge。什么叫三方假设你在 main 分支上要把 feature 分支合并进来第一个版本两个分支的“共同祖先” commit记为 base第二个版本当前所在分支的版本记为 HEAD也就是 ours第三个版本被合并进来的分支版本记为 theirs。Git 拿这三份内容做逐行对比。如果 base 到 HEAD 没变过而 base 到 theirs 改了某些行那 Git 可以直接采用 theirs 的改动反过来如果只有 HEAD 改了那就保留 HEAD 的改动如果两边在同一行各自都做了不同的修改Git 就没办法自动抉择了于是抛出冲突。还有一种情况是两边都新增了同一行比如都添加了同一个方法同样会冲突。这个三方对比模型是所有 Git 图形客户端、IDE 冲突解决界面、命令行冲突标记的共同底层逻辑。你只要理解了它后面看什么工具都觉得通透所谓“解决冲突”其实就是在三方对比的视角下亲手把最终结果合成出来。3. 动手之前先备好两把刷子3.1 三个最常用的不conflicting命令很多教程一上来就教你改文件、敲git add但我强烈建议你先背熟下面几个命令。它们不是解决冲突时用的而是解决冲突“之前”和“之中”用来保命的。git status这个命令在任何时刻都能告诉你 Git 当前处于什么状态。出现冲突时它会用很清晰的列表告诉你哪些文件是“both modified”双方都改动了这就是你的待办清单。git diff不带参数时显示工作区与暂存区的差异。在冲突状态下它会把冲突标记和双方内容一起显示出来配合git diff --ours、git diff --theirs还可以只看某一方的改动非常有用。git merge --abort这是后悔药。只要 merge 还没 commit随时可以执行它Git 会干净利落地把仓库恢复到合并之前的状态所有工作区改动也会退回。新人有时候改着改着把自己改晕了越改越乱最理智的选择往往是直接 abort梳理清楚再重来。此外还有两个查询命令解决冲突之前建议看一眼git log --oneline --graph --all能快速看清你当前的提交图谱git log --merge会列出“正在合并的两个分支中分别改过当前冲突文件的那几个提交”。有时候你并不是唯一的改动者这能帮你定位上一次是谁动过这个文件找他确认一下比你自己硬猜要快得多。3.2 准备一个顺手的工作环境解决冲突这件事工具极其影响体验。我现在的习惯是命令行为主IDE 图形化解决器为辅。两个都要会用。如果你只用命令行只需要一副能看清行号的眼睛和一个现代编辑器。我推荐一下 VSCode它原生支持 Git 冲突标记的颜色高亮冲突区域会有“当前更改 / 传入更改 / 比较更改 / 保留双方”的按钮傻瓜式操作对新手非常友好。如果你在 JetBrains 系 IDEIDEA、PyCharm 等里工作那优势更大。搜索栏里搜到 Git 相关的热搜词不少很多人其实是在 IDEA 里“拉到远端代码”就跑到了冲突界面。IDEA 的冲突解决器是图形化的三方合并面板左边是本地版本右边是远端版本中间是你正在拼接的最终结果。你只需要逐块点选“接受左侧 / 接受右侧 / 两个都保留”然后手动微调中间结果就行。这个界面我在后面实操部分会给出完整截图级别的描述。顺带提醒一下不管用什么工具解决冲突前建议先确保工作区是“可回退”的状态。如果你手头有还没提交的临时改动先git stash暂存起来冲突解决完再git stash pop弹回去。否则你的个人改动会跟合并过程混在一起一旦出问题很难区分责任。4. 完整实操亲手制造一次冲突并解决它4.1 先动手复现一次冲突不怕丢脸地说我第一次学解除冲突时觉得最头痛的不是操作而是“我怎么触发一次冲突”。搞了半天没有冲突自然没法练手。下面从零开始教你一次性稳定复现。假设你准备了一个测试仓库里面有一个calc.js文件初始内容只有一行function add(a, b) { return a b; }然后创建两个分支模拟两位开发者各干各的# 初始化仓库提交初始版本 git init git add calc.js git commit -m init # 创建并切换到 feature/login 分支 git checkout -b feature/login此时在两个分支上各自修改同一行。比如在feature/login分支上改成function add(a, b) { const sum a b; return sum; }提交git add calc.js git commit -m refactor add on feature切回主分支git checkout main再把同一行改成另一种写法function add(a, b) { return a b 0; }提交。现在两边的工作都建立在同一个初始 commit 上但同一行内容已经不同。执行合并git merge feature/login恭喜你你会看到经典的提示Auto-merging calc.js CONFLICT (content): Merge conflict in calc.js Automatic merge failed; fix conflicts and then commit the result.这就是最标准的复现路径。以后你想练手任何时候都能快速搭一个这种最小化实验环境。4.2 把冲突标记读透 的玄机冲突发生时Git 会把冲突文件的内容改成一种“带有标记”的状态。打开calc.js你会看到长这样 HEAD function add(a, b) { return a b 0; } function add(a, b) { const sum a b; return sum; } feature/login请把这个当密码表一样背下来 HEAD到之间的是**当前分支ours**的版本也就是你合并前所在分支上的内容到 feature/login之间的是**被合并进来的分支theirs**的版本每一处冲突都会有这么一组完整标记。你要做的就是把整段标记连同冲突内容一起改写留下你认为正确的最终版本。比如决定两边都保留一部分function add(a, b) { const sum a b 0; return sum; }然后把这些标记行、、彻底删掉。记住最终提交的代码里绝对不能残留任何冲突标记。常见的一个坑是文件太多改花了眼结果把这种东西留在代码里那编译或者 lint 必然爆雷。4.3 手工完成合并并提交冲突标记搞完接下来就是三步走# 1. 将修改后的文件标记为“已解决” git add calc.js # 2. 确认本地合并状态检查是否还有未解决的冲突标记 git status这时状态会从 “both modified” 变成普通的已暂存状态。随后直接 commit注意 commit 时 Git 已经帮你填好了一条默认的合并消息比如 “Merge branch feature/login into main”你可以直接保存退出如果想补充说明也可以改成更有信息量的内容比如 “Merge feature/login: 部分保留 login 改动”。git commit到这里这次合并就算真正完成了。对于一个文件、一处冲突的场景以上流程足够用但现实世界往往是一个 merge 里同时冲突十几个文件那就需要一条更稳的主线流程我在 4.5 节会再给一套完整清单。4.4 用 IDEA 的图形化冲突解决器命令行流程虽然通用但文件多的时候图形化界面远比肉眼扫描几百个标记高效。我在 IDEA 里解决冲突的标准操作是这样的执行完git merge后发现冲突IDEA 右下角会弹出通知或者 Git 面板里文件会显示为红色。这时我打开任意一个冲突文件右侧编辑器会自动进入合并界面左边是本地版本ours中间是合并结果区右边是传入版本theirs底部还有一条可拖动的变更预览条。接下来就是逐块处理界面中用颜色标出的冲突区域。每一种冲突块IDEA 会给你四个选项接受左边Accept Left保留本地版本这一块接受右边Accept Right保留传入版本这一块组合Merge两个版本都拼进去相当于把双方代码都保留然后再手动删减比较Compare左边和右边逐字对照适合想确认差异来源时使用。遇到一块点一下中间结果区会实时刷新。全部处理完之后点击右下角的“Apply”按钮IDEA 会在后台帮你执行git add文件自动进入已暂存状态。之后你继续处理下一个文件直到所有冲突文件都变成绿色再回到 Git 面板点 Commit 提交即可。这套图形化流程最适合多文件冲突或者你需要频繁“保留双方改动”的场景。IDEA 那个“组合”按钮对比命令行的手动拼接省掉不少错位风险。不管你有没有用 IDEA 的习惯我都建议至少学会它解决冲突的界面遇到复杂情况时能救命。4.5 合并后千万别忘记验证代码敲完、冲突标记清了、git add也做了并不代表这次合并“成功了”。我见过不少人git commit之后直接git push然后 CI 红一片。别忘了你刚才是在“裁判”一份连 Git 都无法替你决定的内容你组合出来的代码逻辑上有可能是有问题的——比如两边分别改了同一个函数的不同调用点你合并后虽然语法正确但行为却违背了预期的业务逻辑。所以我的习惯是任何 merge 冲突解决后至少做三件事因为多数冲突发生在代码层面我至少会跑一次本地编译或单元测试确认没有语法错误、没有把标记行残留进去针对合并时有争议的逻辑自己再走一遍关键代码路径——简单说就是打开相关文件看看组合逻辑是否符合合并双方的意图然后才提交合并推送代码。如果是大项目本地全量测试跑不动那至少要把你改过的文件跑一遍相关测试。没有编译通过的 merge坚决不要 push。5. 高频场景拆解不止“同一行改两遍”5.1 五种最常见的冲突类型速查现实中的冲突远不止“同一行改两遍”这么简单。我整理了一个速查表都是我这几年来高频率遇到的类型冲突类型典型表现解决思路内容冲突同一文件同一区域被两边各自修改手动选择保留谁或组合双方文件重命名冲突一边改文件名一边在原文件里加内容用git mv确认新文件为最终路径把改动合进去添加/删除冲突一边删除了文件一边修改了文件内容决定文件是重新保留还是按删除处理二进制文件冲突图片、jar、Excel 等非文本文件被双方各自替换人肉对比产物一般选 one 的版本或重新导出行尾符/字符编码冲突明明没改几行却冲突大半个文件统一.gitattributes与团队编辑器的行尾设置大多数人的第一反应是“内容冲突”但我建议你把后几种也放进视野特别是行尾符冲突非常坑。Windows 默认 CRLFLinux 和 macOS 默认 LF如果仓库里没有.gitattributes统一规则你拉一个文件下来没动几行commit 之后合并会发现一片冲突因为 Git 认为整文件所有行都变了。这种“假冲突”最浪费生命。5.2 二进制冲突不能用编辑器直接合并的文件二进制文件图片、设计稿、DLL、打包产物冲突时你没法打开编辑器去看标记因为标记根本不存在。Git 会提示CONFLICT (binary): logo.png deleted in feature/login and modified in HEAD态度很明确你自己去人工处理Git 不会帮你合并。常规做法是决定保留哪一份git checkout --ours logo.png或者git checkout --theirs logo.png然后git add。但我在实际中更推荐的做法是去和改动文件的人对一下明确两份二进制的差异目的让设计师或产品重新导出一份最终版提交而不是随便选一个。因为两个版本可能一个是加了个按钮一个是换了套配色你的“保留我方”很可能把对方的成果丢掉。5.3 Rebase 时的冲突又不一样说到冲突很多人没意识到 merge 和 rebase 的冲突处理在命令行上“长得一样”但背后的心流完全不同。git merge是一次合并两个分支冲突解决后commit就行而git rebase是把当前分支的若干提交逐个重新嫁接到目标分支之上因此它会在你的每一个提交上依次检查冲突。这意味着一次 rebase 过程中可能出现多次冲突第一个提交有冲突解决完git add后执行git rebase --continueGit 继续去处理下一个提交可能又冲突了又要解决一次直到所有提交重放完毕。每一次解决的都是“当前这个提交与目标分支之间的差异”场景可能完全不同需要保持耐心。需要特别提醒的一个操作是如果你在 rebase 过程中感到局面失控不要慌别去手动乱删.git/rebase-merge这种目录。直接执行git rebase --abort你当前分支会回到 rebase 之前的状态什么都没有损失。很多新人不知道这个后悔药硬着头皮在那里手工 commit 一堆半成品最后把历史搞得一团糟。6. 常见问题与排查技巧实录6.1 我在实际操作中踩过的坑第一个坑冲突文件里挑完了标记却忘了git add就直接 commit。Git 在这种情况下不会让你提交会提示 “You have unmerged paths”。正确的招呼手法是先 add 再 commit。新手总在这里卡住觉得明明改好了为啥不让提交。记住在 Git 的眼里“文件没乱”和“你确认过文件没问题”是两回事add 就是你的“确认”动作。第二个坑合并到一半手滑把别人的分支删了或者忘记了当前在哪个分支。解决方案仍然是一套git status看状态用git branch --show-current确定当前分支如果操作混乱就直接git merge --abort从头再来。别靠记忆靠命令输出。第三个坑解决冲突时不小心把别人的改动全部丢弃典型的例子是 leag cy 团队只能从头手拼代码。原因是某些图形工具里面“接受左边”可能意味着“完全不用右边”而你根本没意识到它把所有文件都覆盖了。我的对策是用git diff --ours --stat和git diff --theirs --stat先看看双方各改了哪些文件确认每个文件确实需要保留哪一方再做批量操作。6.2 常用排查对照表理想动作实际问题排查命令解决动作merge 后想退出合并发现冲突太乱、思路不清git status确认处于合并状态git merge --abort回滚合并rebase 中想退出rebase 多个 commit 冲突层出git status确认 rebase 中git rebase --abort回滚 rebase想知道几个文件冲突手动一个文件一个文件翻git diff --name-only --diff-filterU列出冲突文件逐个打开处理想要某一方完整版本不想手工挑选合并git checkout --ours 文件或git checkout --theirs 文件然后git add提交想查冲突文件中某一边的具体改动不清楚另一分支到底改了什么git diff HEAD...BRANCH_NAME -- 文件路径与对方沟通确认取舍这个表其实也是我自己的“速查清单”。真正遇到问题时别去搜索引擎现查先把表过一遍多数操作都能自己拿下来。6.3 三个减少冲突的团队小习惯最后一个部分我想聊聊“如何让冲突出现得少一点”。说实话冲突无法彻底避免但完全可以大幅减少。我自己经历过几个项目从三天两头冲突到后来几周碰不上一次靠的就是下面三个习惯小步提交、尽早合并。每次提交尽量小改动点尽量少分支随时和主干保持同步。合并不频繁并不代表冲突更少而是每次冲突拆小之后解决成本低得多。反之一个分支闷头写了两周的代码合回来时一冲突就是成百上千行谁也招架不住。模块拆分做清楚。两个团队尽量不要频繁地修改同一批文件和函数。前期做好代码分层和接口划分比你后期花时间解冲突划算得多。用git pull --rebase代替直接git pull。直接git pull会生成一条多余的 merge 记录让历史变脏用 rebase 会让本地提交干净地“长”在远端提交之上是保持线性历史的现代化做法。不过要注意rebase 会改写提交哈希只适合处理你自己本地还没推上去的提交一旦提交已经推到公用分支就不要用 rebase 去动了。7. 一些写在最后的个人体会我个人在实际操作中的体会是解决 Git 冲突技术本身其实只占一半另一半是稳定的心态和清醒的判断。很多人一看到冲突就紧张手忙脚乱地在所有文件里反复试反而搞出更多问题。我的习惯是先把git status拉出来看一遍明确冲突文件清单然后从最简单的文件开始解决每解决一个就git add一个遇到不确定的取舍绝不硬猜去和改动过的同事确认一下意图通常三十秒就能说清楚省下的却是半小时的返工。再分享一个小技巧如果你在合并过程中临时想对比“解决前”和“解决后”的效果可以用git stash把半成品暂存或者先复制一份冲突文件到项目外的临时目录留作对照。很多复杂合并中出现的问题其实不是内容问题而是“我改到一半忘了最初是什么样”。还有一点挺重要的——别怕亲手制造一次冲突。你在学习的时候刻意创建两个分支故意在同一行做相反的修改然后反复 merge、abort、rebase直到所有过程都烂熟于心。Git 是把双刃剑熟练之后它就是你项目里最可靠的保险丝而如果你对它一知半解它也能让你一个下午都耗在恢复代码上。所以宁可花一个小时练习冲突解决也不要把隐患留到上线前一天爆出来。希望这篇里写到的流程、经验和小坑能帮你少走一段弯路。
：从迭代权重到路径系数)
