很多人刚接触 Git 时，最困惑的往往不是那些 push、pull、commit 的基本操作，而是“分支到底是怎么走的”“为什么我明明什么都没动，一拉代码就冲突了”。我自己带过不少前端同事和实习生，几乎每个人第一次遇到 merge conflict 的时候都是一脸懵，甚至有人直接吓得不敢合并代码。其实冲突并不可怕，它只是 Git 在告诉你：两个改动都碰了同一块地方，我拿不准谁说了算。搞懂 Git 的工作机制，自然就能理解冲突为什么产生，也就有了解决它的底气。
这篇文章我会从 Git 底层的对象存储、分支指针、三个区这些基础说起，讲到三方合并的具体过程，再拆解冲突出现的几种典型场景和对应解法。内容尽量照顾到不同阶段的读者：刚入门的人可以把第一部分当成避坑手册，老手可以直接跳到冲突实操和工具配置部分。开写之前先说明一句：整篇是按我自己实际使用的经验来写的，涉及的部分命令在不同 Git 版本下可能略有差异，但底层逻辑是一致的。
1. Git 的基本工作机制：从三个区到一颗“提交树”
1.1 三个区：工作区、暂存区、版本库
Git 的日常操作，本质上是在三个区域之间搬运内容。工作区（Working Directory）就是你电脑上能直接看到的文件目录，我们改代码就是改这里的文件。暂存区（Staging Area / Index）是 Git 内部的一个中间层，你可以把它理解成一个“购物车”，第一批文件改完先推上车，第二批改完再推上去，最后统一结账。版本库（Repository）则是 Git 真正存储历史记录的地方，每一次 commit 都会在这里留下一个不可变的快照。
我见过很多新手犯的最典型错误，就是以为git add是提交，实际上它只是把改动从工作区放进了暂存区，真正落库的是git commit。这不算什么问题，但如果混着用，经常会出现“我明明改了文件，为什么 push 上去没有我的内容”这种疑惑。所以第一条经验就是：脑子里画清楚这三条线——改的是工作区、存的是暂存区、记的是版本库。
这里还要提一个常用但容易被忽略的概念：git status不是摆设。你可以随时通过它看清楚当前工作区、暂存区和版本库之间的差异状态。我每次动手前几乎习惯性先跑一下这个命令，它能避免后面一大半的混乱。
1.2 分支与 HEAD：Git 的“指针游戏”
Git 的分支和传统 SVN 的分支完全不同。SVN 的分支是把文件原样复制一份到新目录，而 Git 的分支只是一个轻量级的可移动指针，指向某一次提交。每次你进行新的提交，当前分支的指针就会自动指向这个新提交。所以 Git 创建分支无比快，正是因为不用复制文件，只是新增一个只有几十字节的引用文件而已。
当你在 Git 中执行git branch feature的时候，系统只是基于当前提交新建了一个指针名字；执行git checkout feature或git switch feature，则是将 HEAD 这个“当前指针”移动到 feature 指向的提交，并把工作区同步成那个提交的内容。
理解“分支是指针”这一点特别重要。因为冲突的本质，正是多个分支指针各自向前走了各自的路径，当它们要“汇合”时，目标内容已经分道扬镳。引用一句实际操作的体会：我在带新人解决冲突前，都会先让他们画一下当前提交图，用git log --graph --oneline --all看清分叉点在哪里。这比直接盲目执行合并有效得多。
1.3 提交对象与不可变性
这里再往深挖一层，给你解释提交的存储模型，因为它是理解三方合并的基石。
Git 的核心存储是一个内容寻址的文件系统。每个被跟踪的文件内容会被计算出一个 SHA-1 哈希值；Git 以这个哈希作为文件名，把文件内容存进对象库。每次提交时，Git 会生成一棵“目录树对象”，记录当前项目中所有文件和目录的层级结构，每个文件项都指向对应内容的哈希对象。提交对象本身则记录了根目录树对象的哈希、父提交的哈希、作者、提交时间和提交信息。
有了这个机制，Git 才能实现不可变历史：一个提交一旦建立，它的内容和父亲关系就完全固定，无法直接修改。所谓的“修改历史”，其实是另外生成一个新的提交对象并挪动指针，旧对象如果没人引用，会被后续的垃圾回收机制清理掉。
这个模型也解释了为什么 Git 的合并能够做到比较精确：因为每个文件版本、每颗目录树都有独一无二的校验和，Git 可以快速判断两个版本的差异点，而无需逐行全文对比。
2. 冲突的产生机制：在合并时究竟发生了什么
2.1 三方合并的概念
为了说清冲突，必须先搞清楚 Git 合并时最核心的动作——“三方合并”。三方指的是：当前分支的提交（我们叫它 HEAD 或 ours）、待合并分支的提交（theirs），以及这两个分支的共同祖先提交（merge base）。
多数时候，两个分支各自修改了不同的文件，Git 会自动完成合并。它的判断规则大致是：如果一个文件只在一侧被修改而另一侧没动，那就直接采纳修改的那一侧；如果两侧都改了，但修改的区域互不重叠，Git 也能自动合并，保留两边的改动。
真正让 Git 束手无策的是：两侧都修改了同一文件的同一块区域。这时 Git 没法判定应该保留哪一个实现，于是它会把冲突标记嵌入到文件内容里，中止自动合并，等待人来裁决。可以说，冲突的本质不是“Git 出错了”，而是“程序逻辑上出现了真正需要人工决策的分歧”。
给个比较简单直观的类比：就好比你和你同事同时在一份文档的第三页第二段加了自己的内容，后写的人在保存时发现原本的段落已经被前一个人改了，这时候不管你用什么工具都没法毫无逻辑地合并两份改动。你必须自己去看，两个人写的内容谁该留、谁该让。
2.2 常见的冲突触发场景
虽然核心触发条件只有“同一区域被多侧修改”这一条，但实际开发中触发这个条件的场景五花八门，我挑几个最常见的说一下。
第一个是长时分支合并。你从 main 拉了个 feature 分支，埋头做了一个月的功能，等你回头合并的时候，main 上其他人也改了不少代码。两边如果恰好动了同一个模块（比如公共接口文件、工具类文件），冲突概率极高。团队协作越频繁、代码库越集中，这种冲突就越难避免。
第二个是多人同时改了同一块配置或资源文件。比如 package.json、pom.xml、国际化语言包。这类文件往往由很少的几次提交承载大量键值，每个人改了不同的位置，但在 Git 眼里，它们完全可能落进同一个 diff 区段里，导致冲突。
第三个是代码格式化与重构带来的“噪音冲突”。有人提交过把整个文件从双引号改成单引号，有人把函数拆到新文件又改回原文件，结果拉日志一看没有多少真实冲突，反而是格式化差异互相覆盖。这种情况目前没有万能解法，最有效的缓解手段只有约定统一格式化工具，并且尽量在专属分支里做格式化，再单独提交一次。
2.3 冲突标记到底在说什么
当冲突发生后，你打开冲突文件，会看到类似这样的标记：
<<<<<<< HEAD 当前分支的代码 ======= 待合并分支的代码 >>>>>>> feature/xxx这三段标记很容易看懂：<<<<<<< HEAD和=======之间是当前分支上的内容，=======和>>>>>>> feature/xxx之间是来自于目标分支的内容。这个“标记块”称之为冲突块，可能一个文件里有多个。
有些人看到代码块变绿变蓝就慌，其实你只要记住一件事：Git 不是让你把标记符号保留进代码里，而是让你决定最终保留哪些行、删掉哪些行和全部标记，然后用git add把结果标记为“已解决”。不把<<<<<<<这种符号清理干净就开始提交，程序多半会编译失败，这也是很多“解决完冲突后程序崩了”的问题根源。
3. 冲突解决方案：命令行手动处理
3.1 标准流程：从 merge 到 add
当你执行git merge feature/xxx出现冲突时，Git 会停下来，在终端明确告诉你哪些文件“both modified”。此时你的仓库处于“合并中”状态，接下来的操作顺序建议按照以下几步走：
- 先执行
git status查看所有冲突文件列表，区分“已解决”和“待处理”。双出有U（unmerged）标记的就是仍需处理的冲突文件。 - 打开冲突文件，逐个查找
<<<<<<<标记，定位每个冲突块。 - 根据你的业务需求，决定保留当前分支内容、保留目标分支内容还是两边都改。
- 清理所有冲突标记符号，确认最终代码符合预期。
- 对所有修改过的冲突文件执行
git add <file>，将文件标记为“已解决”。 - 在确认没有遗漏后执行
git commit完成合并提交。如果你使用的是git merge，提交时 Git 会生成默认的合并提交信息，也可以自己改。
这里有个细节容易踩坑：git add这个命令不会自动把冲突标记清理掉，它只是修改冲突状态。你不改代码内容就 add，虽然在 Git 看来冲突解决了，但项目中可能残留<<<<<<<语法错误，后果很严重。所以我个人的习惯是在 add 前用编辑器或 grep 全文件搜一遍冲突符号，确保一个不剩。
3.2 保留某一侧内容的快速选择办法
有些冲突块特别大，比如两边各自改了一百行接口定义，最后你只想留自己的那一版，手动删别人的内容会很费劲。这种时候可以用更聪明的办法。
如果确定了要“保留当前分支版本”，直接执行：
git checkout --ours -- <file>再把这个文件标记为已解决：
git add <file>反过来，要保留待合并分支的版本，用：
git checkout --theirs -- <file>注意这里的--ours和--theirs在合并时指向的对象：HEAD 代表 ours，被合并分支代表 theirs。但在 rebase 时，语义正好反过来，ours 变成被变基的分支，theirs 变成你重放的提交，这点极容易搞混，建议实际使用前先用git status和git log确认你站在哪一侧。
还有一个参数是-X theirs或-X ours，可以在合并时强制某一侧自动解决冲突，但我不建议默认使用。它们会让 Git 自动丢弃另一侧内容的修改，很容易造成代码丢失。只适合用于明确知道要丢弃哪一侧结果的临时场景。
3.3 如何保留两侧的代码
很多时候业务要求不是“二选一”，而是两边的内容都要合并到一个最终版本里。比如你和同事同时给同一个配置文件增加了不同配置项，那你要做的就不是删除某一侧，而是把两块内容按语法要求组合在一起。
举个例子，如果两个分支各自往同一个 JSON 对象里加了不同字段，冲突块可能长这样：
<<<<<<< HEAD "name": "demo", "timeout": 30, ======= "name": "demo", "retries": 3, >>>>>>> feature/retry最终答案可能既不是单留左边，也不是单留右边，而是合成这样：
"name": "demo", "timeout": 30, "retries": 3,这个过程没有捷径，只能手动编辑。我的建议是最好结合上下文理解冲突，千万不能因为冲突块看着像两个不同字段就偷懒只留一段。有时候两个字段名相同但值不同，还需要进一步去确认新旧代码的调用关系后再做取舍。
3.4 用 git mergetool 和图形化工具提高效率
如果项目规模大、冲突频繁，纯靠手工文本编辑不仅慢，而且容易看漏。Git 原生提供了git mergetool命令，可以配置外部工具进行三方对比界面化解决。
我常用的一个组合是 VS Code + GitLens，因为 VS Code 内置了简洁的 merge editor，而且对冲突块有不错的色彩区分。直接在冲突文件上选择“接受当前更改”“接受传入更改”或“接受两者”，效果很直观，适合大多数开发场景。
如果你更习惯独立工具，Beyond Compare 也是不少人的选择，配置方法是：
git config --global merge.tool bc git config --global mergetool.bc.path "/usr/local/bin/bcomp"之后运行git mergetool即可。
这里要额外提醒一句：启动 mergetool 前建议先用git stash或 commit 确保工作区是干净的，否则工具在保存结果时可能产生额外状态混乱。我自己第一次用 Beyond Compare 时就因为还有未提交的半成品改动，结果工具结束了我还要做二次恢复。
4. 冲突解决后的收尾与常用技巧
4.1 完成合并并验证结果
当所有冲突文件都已处理完、标记为已解决后，千万别直接push了事。合并这一步是代码质量风险最高的时刻之一，我在团队里通常强制要求走一轮最小化验证。
具体来说，至少要执行一次本地构建或测试：
npm run build或者针对你改动的模块跑一次相关测试用例。如果项目涉及数据库迁移、配置文件合并，还要额外留意编译期不会暴露的运行时问题。
验证通过后再执行：
git commit git push如果你用的是git merge，Git 会在提交时自动使用预设的合并信息；如果你想写更详细的内容，可以在 commit 前临时加一句git commit --no-edit来保留默认信息，或者用-m自定义描述。
4.2 合并后的撤销策略
有一种情况很难受：你以为冲突解决了，代码编译也过了，但 push 后才发现业务逻辑其实完全不对。这时候有两种后悔药。
第一种是软恢复：git reset --merge HEAD~1或git reset --hard HEAD~1直接把当前分支回退到合并前。--hard会连工作区改动一起丢，需要谨慎使用；如果只是想把合并提交撤掉但保留所有文件改动到工作区，可以用：
git reset --merge HEAD~1不过如果你的合并提交已经被别人拉取甚至在新提交基础上继续工作了，就不建议重置历史，最好通过新的提交来修正内容。
第二种是对已经 push 到远端且被协作者引用的提交进行反向修补，用git revert -m 1 <merge-commit>生成一个反向提交。这里的-m 1表示保留合并提交的第一父提交（即合并时你所处的分支），放弃被合并分支带来的改动。这属于高阶操作，如果不是特别需要，新手尽量少碰，必要时查文档配合测试来用。
4.3 冲突预防的日常习惯
虽然冲突不可能完全避免，但低冲突或零冲突的团队协作方式是存在的。我在多个项目团队里总结出几条行之有效的习惯，供你参考：
第一，保持小步提交，分支生命周期不要太长。一次提交尽量只改一个可描述的问题，避免把大量修改揉在一起，这样冲突面会大幅缩小。长分支合并的冲突，往往不是因为代码量大，而是因为每行改动混杂了太多职责，无法自动合并。
第二，高频同步主干。即使你的 feature 功能还没做完，也建议定期把 main 合并回自己的分支，或者用 rebase 方式把本地提交变基到最新主干之上。这样可以把冲突分散到多个小阶段，而不是在发布前一晚一次性爆发。
第三，使用 git diff 提前观察差异。合并前先跑git diff main...feature/xxx对比公共祖先以来的差异，可以直观看到哪些文件可能出现冲突。提前和相关同事对齐一下改动点，很多冲突根本走不到执行合并那一步。
第四，约定公共文件的改法。比如 README、package.json、接口定义这类高频冲突文件，尽量通过注释分区、按字典序排列键值、避免无关格式调整等方式来减少 diff 碰撞。听起来玄学，但实测效果很好。
5. Git 合并中容易出现混淆的高频问题
5.1 merge 和 rebase 的冲突处理差异
merge 与 rebase 是解决分支集成的两种不同策略，底层的冲突处理体验也有明显差异。
git merge操作是创建一次新的合并提交，保留两个分支各自的历史轨迹，最终图形会出现分叉再融合。冲突发生时，你处于“正在合并”状态，解决完文件后正常git add与git commit即可。
git rebase则是把你当前分支的提交逐个“摘下来”，在目标分支最新提交之上重新播放。它的提交历史更线性，但每次重放都可能触发冲突。处理一次冲突并git add后，不能直接git commit，而是要执行git rebase --continue，让 Git 继续执行剩余提交的重放。
实际上绝大多数团队会规定：本地未推送的分支可以随便 rebase，但一旦提交已 push 到公共远程分支，就不要再用 rebase 去重写历史，否则协作者的本地仓库会出现大量重复和错乱。如果非要在共享分支上 rebase，至少要和团队沟通清楚并约定强制 push 的策略，否则很容易把别人的提交弄丢。
5.2 stash 和 merge 时的冲突差异
git stash通常不会引入明显的分支冲突，因为它本质上是把工作区改动临时存储起来，不涉及跨分支合并。但在你执行git stash pop时，如果当前分支的工作区已经被其他改动占据，且改动区域和 stash 中的内容重叠，也会出现冲突。解决方式与普通合并冲突类似，但没有三方合并信息，所以 Git 只会把 stash 的改动当成尝试叠加的新内容。遇到这种冲突，多数情况是想清楚旧改动是否还需要再决定去留，盲目跳过容易丢代码。
对比之下，merge 的冲突一定是发生在不同提交历史上的两个分支之间，信息更丰富，处理起来更可预期。这里提醒一句：频繁使用 stash 且不及时清理的人，迟早会遇到“pop 出来冲突得莫名其妙”的困境，建议尽量用临时分支代替 stash 类操作，更安全。
5.3 误删除他人提交的常见恢复方法
这是另一个高频问题：有人在合并时选择了错误的一侧，或者用 reset 硬回退丢失了别人的提交。
如果提交还在本地的 reflog 中，就能恢复。git reflog记录了 HEAD 指针的所有历史移动轨迹，包括被 reset 丢弃的分支位置、被 rebase 覆盖的提交等。找到恢复目标对应的哈希值后，执行：
git branch recover-branch <commit-hash>就能新建分支指向该提交。
如果丢失的提交已经被 push 到远端且远端强制更新，则通常只能靠其他同事的本地仓库把对应提交重新推回来。这也是为什么我们平时不鼓励随意 force push 的原因。万一数据被改得不可收拾，先让所有人停止操作，再比对各自 reflog，往往能捞回大部分内容。
6. 最后再分享几个小细节
如果你还在用老的git checkout切换分支，可以考虑慢慢迁移到git switch与git restore，它们职责更单一，不容易误操作。特别是想丢弃某个文件的改动，用git restore <file>会比 checkout 写法更直观，因为它不会产生“我是不是切换了分支”的困惑。
另一个建议是把默认编辑器从 vi 换成自己顺手的编辑器。Git 在合并需要提交信息、rebase 需要改写说明时都会调用默认编辑器，如果你不熟悉 vi，很可能卡在保存界面动弹不得。配置很简单：
git config --global core.editor "code --wait"这样当 Git 弹出编辑窗口时，VS Code 会直接打开，等你在界面里保存并关闭窗口后命令才继续执行，体验友好很多。
我个人实际踩过几次坑后，还养成了一个习惯：在开始解决复杂冲突前，先执行一次git diff --check，结合编辑器搜索<<<<<<<、=======、>>>>>>>确保没有残留冲突标记，再执行 add 和 commit。这套流程虽然朴实，但能最大限度地避免“假解决”引发的事后返工。希望这篇关于 Git 工作机制与冲突解决的内容，能帮你把分支、合并和冲突这些概念串成一条清晰的线。下次再撞上冲突，不要慌，拆开标记、读懂三方差异，你会发现“冲突”不过是 Git 提供的一次高质量的代码评审机会。
