Git合并冲突实战指南：从三方合并原理到解决流程与特殊场景

1. 冲突不是灾难，是 Git 给你的一次强制对话

先别急着复制粘贴覆盖文件。很多新手（甚至不少老手）碰到CONFLICT这两个字就慌了，第一反应是git checkout --ours或者干脆把对方代码手动改成自己想要的版本。我见过太多次因为这种“暴力解决”导致最终合并进主干的代码，既丢了别人的功能，又留下了没人看得懂的残留注释。

Git 合并冲突的本质，是两个分支在同一个位置对同一份内容做出了不同的修改，它自己无法判断谁的意图优先级更高，所以停下来等你拍板。这跟两个人同时改同一份合同里的同一个条款是类似的，你不可能让机器替你决定哪一版更有道理。Git 把决定权交还给你，这不是 bug，而是最合理的设计。

所以我的第一建议是：把冲突当作一次代码审查的契机，而不是麻烦。你在解决冲突的过程中，实际上是在和另一位开发者进行异步代码评审，你会被迫了解对方改了哪些逻辑、跟上一次提交相比差异在哪、这些改动和你的分支是否互相抵触。这个动作做完一遍，你对整个项目结构的理解往往会上一个台阶。

这篇东西我会从冲突产生的底层原理说起，然后一步一步演示标准解决流程，再把各种常见场景——包括很多人栽过跟头的master分支revert之后、其他分支再合回来时冲突爆炸的情况——单独拉出来讲透。最后给一份排查速查表，希望能帮你以后遇到冲突时，能气定神闲地一步步处理完，而不是在终端里满头大汗。

2. 搞清楚 Git 为什么会对同一段代码“无法抉择”

2.1 合并冲突的本质：三方合并（Three-Way Merge）

要理解冲突，必须先理解 Git 合并的基本方式：三方合并。很多人在学 Git 时，把它想象成“对比两份文件，把不同的部分拼在一起”，听起来简单，真这么做会出大问题，因为你不知道哪边的改动是新的、哪边是旧的。

三方合并引入了第三个参照物：两个分支的共同祖先（merge base）。假设你从master拉出一个分支feature，之后两个分支各自演化。现在要把feature合回master，Git 会这样处理：

• 读取master当前版本的文件（我们叫它ours）；
• 读取feature当前版本的文件（我们叫它theirs）；
• 找到两个分支在分叉点上的同一个文件的版本（我们叫它base）。

合并时，Git 依次比较这三者的关系：

• 如果base到ours有改动，且base到theirs没有改动，那就以ours为准；
• 如果base到ours没有改动，且base到theirs有改动，那就以theirs为准；
• 如果两边都改了，但改的是不同区域，Git 自动把两块改动都保留下来；
• 如果两边都改了，而且改的是同一区域，Git 无法判断谁覆盖谁，只能产生冲突。

这就是为什么有些人会疑惑：“我明明只是改了文件开头，对方改了文件结尾，为什么没有冲突？”因为改动区域不重叠，Git 可以安全地同时保留，自动合并成功。而要是你俩恰好修改了同一行，哪怕改出的结果一字不差，Git 也会停下来让你确认。

这个概念必须刻在脑子里，因为它直接影响你解决冲突时的判断思路：你要做的不是“挑一个好版本”，而是对照base版本，确认两边各自的意图，然后把两个意图合理地融合到最终结果里。

2.2 冲突标记长什么样，每一行都在说什么

当冲突发生时，Git 会在冲突文件里嵌入标记。如果你用cat或者编辑器打开，会看到类似下面的内容：

function init() { <<<<<<< HEAD enableLogging(true); initCache(); ======= enableLogging(false); >>>>>>> feature/login initNetwork(); }

我来逐行解释这些标记的含义：

• <<<<<<< HEAD：冲突区域的起点，后面跟的是当前分支的引用名。HEAD表示当前检出的分支，也就是“我这边”的版本；
• =======：分隔线，上面是当前分支的内容，下面是合并进来的分支的内容；
• >>>>>>> feature/login：冲突区域的终点，feature/login是正在被合并进来的分支名。

上面这个例子里：当前分支在init()里调用了enableLogging(true)和initCache()，而feature/login分支只调用了enableLogging(false)，且没有初始化缓存。

看到这里，正确的处理方式不是删掉任意一边，而是想清楚：这两段代码表达的是什么逻辑？是否应该同时保留？比如最终结果可能是：

function init() { enableLogging(false); initCache(); initNetwork(); }

也就是说，日志开关采用对方分支的配置，但缓存初始化必不可少。这时候冲突就不是“二选一”，而是“取两边的合理部分”。

注意：冲突标记里的HEAD不一定就是当前分支的名字，它只是 Git 用来指代当前检出的分支。如果你在执行git rebase，那HEAD指向的是你正在变基的分支，而合并进来的内容来自被变基的目标分支，语义会反过来。这个细节很多人搞混，后面我会专门讲。

2.3 常见误区预警：避免“无脑保留”“无脑删除”

我在实际项目里见过不少人解决冲突的思路就是“哪个看着顺眼留哪个”。这确实快，但它有几个隐患：

第一，你丢掉了对方分支里精心设计的功能。开发者的代码风格千差万别，你的分支上可能没有对方的抽象层级，直接删掉对方的实现，等于把对方的工作全部作废。后续对方发现功能失踪，排查一圈，最终定位到你的那次合并提交，同事关系就直接“拉满”。

第二，你在毫无记录的情况下，把两段逻辑揉在了一起。有时候，冲突区域里的两段代码并不是完全互斥的，它们可能各自调用了一个关键函数，正确做法是同时调用。如果你偷懒只保留一个，程序可能在特定场景下崩溃，而因为你已经解决了冲突，Git 层面不会再有任何提示，这个 bug 潜伏期可能长达数周。

第三，也是最重要的一点：你失去了了解他人代码逻辑的机会。每解决一次冲突，你都能借机比对双方的代码设计和意图。这种收获，在实际工作中远比“合并成功”这个结果更有价值。

所以，遇到冲突时，不要急着删。先把冲突区域的上下文整体读一遍，搞清楚双方各自在做什么，再动手。如果你发现自己对某段代码完全陌生，先git log看看对方分支的提交历史，或者直接去问写这段代码的同事，都比盲改来得靠谱。

3. 正确处理冲突的标准流程：从拉分支到合并的完整步骤

3.1 动手之前：先看清当前状态

无论你是执行了git merge、git pull还是git rebase遇到冲突，第一件事永远是看一眼仓库状态，弄清楚冲突范围、涉及文件和当前所处的操作阶段。这是整个流程里最不能省略的一步。

git status

输出结果会明确告诉你当前是否处于merge状态、有哪些文件是both modified（双方修改）、哪些是deleted by us/theirs等。我把常见状态整理一下，方便你对照理解：

接着用这条命令查看每个文件的具体冲突块数量和位置：

git diff --name-only --diff-filter=U

或者更直观一点，直接看冲突内容：

git diff

此时，git diff显示的是工作区与暂存区之间的差异，而由于合并冲突状态下文件处于特殊状态，你会看到冲突标记。配合 VSCode、IDEA 或者 Sublime Merge 这类图形化工具查看，会舒服得多。

图形化工具不是必须的，但确实能提高效率。以 VSCode 为例，它会把冲突区域高亮显示，并提供“Accept Current Change”“Accept Incoming Change”“Accept Both Changes”三个快捷键按钮。我个人的经验是：快捷键很快，但不要盲点，还是要先看清两个版本各自的内容再选。

3.2 核心步骤：手动编辑冲突文件并完成暂存

假设你的冲突文件是src/utils/format.js，里面有两个冲突块。首先用编辑器打开它，逐个处理冲突区域。处理原则我已经强调过：先理解，再动手。具体操作步骤如下：

1. 定位到第一个冲突区域（搜索<<<<<<<即可）；
2. 阅读当前分支版本（HEAD标记到=======之间的内容）；
3. 阅读合并分支版本（=======到>>>>>>>之间的内容）；
4. 判断两个版本的意图：是二选一，还是复合两者；
5. 编辑该区域，删除所有冲突标记，保留最终需要的代码；
6. 重复上述步骤，直到文件中不存在任何<<<<<<<标记；
7. 保存文件，执行git add将该文件标记为“已解决”。

执行git add这一步非常关键。Git 只认暂存区，你手动改了文件但没git add，对 Git 来说这个文件仍然是“未合并”的状态。只有当你git add之后，Git 才会认为这个冲突文件被解决。

全部文件都处理完成后，再次运行git status，确认没有遗留的both modified或unmerged文件。然后执行：

git commit

这条命令会生成一个合并提交。Git 默认会给你准备好提交信息，内容类似Merge branch 'feature/login' into master，你可以保持默认，也可以补充一些说明，比如解决冲突时做了哪些取舍。合理的合并提交信息对后续查阅历史非常有帮助。

3.3 解决冲突的三种可视化工具，选哪个看习惯

如果你觉得手动查找<<<<<<<标记效率太低，可以考虑这几类工具：

第一种是编辑器内置的冲突提示。VSCode 和 JetBrains 全家桶（IDEA、PyCharm、GoLand 等）都内置了冲突解决界面。它们会把两边的版本并排显示，你能直观看到差异，然后一键接受或合并。这是我日常用到最多的方式，也是我推荐新手从最先尝试的方式，因为学习成本几乎为零。

第二种是专门的可视化合并工具，比如kdiff3、Meld、Beyond Compare。它们可以展示三栏对比：base、ours、theirs，并且能手动从每一栏选取片段到结果栏。这种方式特别适合复杂的、冲突块较多的文件，因为你能看到共同祖先版本，理解双方的改动逻辑会容易很多。配置方式如下：

git config --global merge.tool kdiff3 git config --global mergetool.kdiff3.path /usr/bin/kdiff3

然后在冲突状态下执行：

git mergetool

Git 会逐个打开有冲突的文件，等你操作完再关掉编辑器，然后问你“Was the merge successful?”你确认后，它会自动执行git add。

第三种是命令行工具，比如直接看git diff输出。这种方式对终端党友好，但个人觉得只适合解决简单冲突，复杂冲突不如上面的可视化工具清晰。

我之前碰到一次特别复杂的冲突，一个文件出现十几个冲突区域，两边还都做了不少重构。用纯手改的方式，不到 10 分钟就眼花缭乱了，后来切成kdiff3，按base版本逐行梳理，半小时才完全搞清楚。别看前期配置麻烦了点，遇到真实场景省下的时间可太多了。

3.4 选好“拉取”时机，可以在源头减少冲突

很多人习惯每天上班第一件事就是git pull origin master，这个动作本身没问题，但如果你在自己的功能分支上工作，我的建议是：每天至少把主干的最新代码合进自己的分支一次。

具体做法是：

git checkout feature/my-work git fetch origin git merge origin/master

这不会直接影响主干分支，冲突只发生在你的本地工作分支上。你有充足的时间在提交给同行评审之前把冲突处理干净。相反，如果你一直埋头苦干，等一个星期的功能开发完，直接发merge request合并到master，那这个冲突规模往往会让你怀疑人生。

还有一个团队习惯值得推荐：对短期存活的分支，尽量用 rebase 而不是 merge。短期分支（比如两三天内合回主干的修复分支），用 rebase 可以让提交历史变成一条直线，后续合并到主干时不会产生多余的合并提交。但注意，rebase 会改写提交历史，如果有其他人基于你的分支干活，就别这么做。

这里顺带提一个非常核心的实操建议：git fetch之后用git merge origin/master而不是直接git pull origin master，这两者其实不相等，git pull等于 fetch + merge，但有时候你只想先看看远端变更再决定怎么合并，fetch更安全可控。

4. 特殊场景专项解析：revert之后的分支合并、amend、丢弃式合并

4.1master分支revert之后，其他分支合并回master的冲突怎么处理

这是网上搜索热度极高、实际工作中特别容易踩坑的一个场景。我详细说一下。

假设你的master分支有一个提交 A，做了一些重构，后来发现这个重构有问题，于是你在master上执行了：

git revert A

git revert不是删掉提交 A 的记录，而是产生一个新的提交 B，B 的内容是“抵消 A 的改动”。此时，master的代码历史里同时存在 A 和 B，但代码内容回到了 A 之前的状态。

关键在于，你的特性分支feature是基于包含 A 的master拉出来的，而且你没有把 A 的缺点同步到该分支上。这时候你把feature合并回master，Git 会怎么处理？

它会发现：

• base是master和feature分叉之前的状态（不含 A）；
• master当前状态有了 A 和 B，相当于对base的净改动为零；
• feature当前状态含 A 的改动，再加上新开发的内容。

于是 Git 认为：master没有净变化，但feature有变化，合并时应该直接应用feature的改动。然而问题来了：feature上的 A 改动在master历史里已经不存在了，因为被 B 抵消了，可 Git 的合并逻辑是基于提交差异的，它只知道feature在base基础上改了很多，其中就包括 A 所触及的那些行。当这些行在master上已经不存在、被B恢复到了旧状态时，合并会产生大量冲突。

这个场景的典型冲突表现是：你需要合并的代码行在master上已经“被改回去了”，而feature还是“改过之后”的状态。此时如果你无脑选择ours（即保留master状态），那feature上 A 的改动就会彻底消失；如果无脑选择theirs（即保留feature状态），你之前在master上 revert 的问题会“复活”。

正确做法是什么？分成两种情况：

情况一：master上 revert 的提交 A，在feature上其实已经被你手工修复好了。这时候，你在冲突区域应该保留feature的版本，因为它包含修复后的正确逻辑。但要特别注意，feature必须确实包含对应的修复提交，否则不要这样做。

情况二：master上 revert 的提交 A 确实有问题，feature还没有修复这个 bug。这时候正确做法是：合并时先保留master状态（即ours），然后回到feature上围绕冲突区域做新的修复代码，而不是把旧代码原封不动带回来。

我在实际操作中更推荐一个稳妥方案：在把feature合并回master之前，先把master（包含 revert 提交）合并进feature，在feature上解决这些冲突，验证通过后再往master合并。这样至少冲突解决发生在你自己的分支上，有充分的时间测试，不会破坏主干。

4.2 想要重新定义合并方向：git merge -X theirs与-X ours的代价

有些人为了图快，会直接这样处理冲突：

git merge -X theirs feature/login

这个命令的意思是：合并时遇到冲突，直接采用theirs的版本，完全不弹冲突提示。同理，-X ours就是遇到冲突时采用当前分支版本。

这两个选项确实快，但使用场景非常有限。我的建议是：只在明确知道冲突方向的情况下用于临时快速合并。比如你只是想临时看一下分支合并后的构建结果，不关心细节，可以这么干。但最终往主干合并时，还是老老实实逐个解决冲突。

因为-X theirs会在冲突块级别自动选择，而不是在语义层面做正确合并。它不会告诉你“这个冲突块的两边代码其实应该同时保留”，它只是粗暴地帮你做了个二选一。尤其当合并分支里有人重构了接口、函数签名，而你保留的是旧调用方式时，代码可能连编译都过不了。

还有更极端的.gitattributes里的merge=theirs策略，我基本不推荐在生产项目里用，除非你有十足的把握。

4.3 关于git commit --amend和它引发的合并冲突

另一个热搜词是git commit --amend。虽然它本身不直接引入合并冲突，但它和冲突有一个间接关系：如果你对一个已经推送到远端的分支使用amend，就会改写提交历史，导致该分支和远端不同步，后续合并时产生莫名的冲突。

git commit --amend的用途是修改最近一次提交的提交信息，或者把暂存区里的小改动追加到最近一次提交里。比如：

git add src/format.js git commit --amend

它会打开编辑器让你修改提交信息。如果你想保留原提交信息和作者，不改变内容地补一句说明，也可以：

git commit --amend --no-edit

我的建议是：amend只用于处理尚未推送到远端的本地提交。一旦某个提交已经被其他人拉取，amend会重写历史，两边分叉后，后续合并该分支时，Git 无法简单识别改动意图，很容易产生大量冲突，这是典型的“自己制造冲突”的操作。

如果你已经误把amend后的分支推到了远端，那么对这个分支的同步，需要使用强推（force push）这种方式，但这会覆盖远端历史，对协作影响很大，所以要格外慎重。这里多说一句：如果必须强推，记得提前通知团队成员，否则他们在旧历史上的提交会“凭空失踪”。

4.4 安装与环境配置不到位，是很多人做不好 Git 的隐形原因

这里要插播一个看似无关、但实际影响深远的点：很多人对 Git 的操作不熟悉，根源不是概念不懂，而是环境配置不到位。热搜词里有大量“git 安装”“git 安装教程”“git 配置 gitee 密钥”这类搜索，说明这一步就拦住了不少人。

我建议大家在开始折腾复杂合并之前，先把基础环境收拾利索：

• 安装完 Git 后，第一时间配置用户名和邮箱，否则无法提交：

git config --global user.name "Your Name" git config --global user.email "you@example.com"

• 配置 SSH 密钥以便远程仓库免密操作。以 Gitee 为例，生成密钥后，把~/.ssh/id_rsa.pub的内容添加到 Gitee 账号的 SSH 公钥列表里即可。不能正常clone/push的分支操作，什么合并都无从谈起。
• 设置一个合适的默认编辑器。如果每次提交信息弹出的都是 Vim，而你又完全不适应 Vim 的操作，会非常难受。改成 VS Code 或者 nano：

git config --global core.editor "code --wait"

这些基础配置看似琐碎，但真的能救你于水火。我见过有人因为不会退出 Vim，把提交信息乱改一通，最后把半成品代码提交上去还引发了一系列连锁冲突问题。

5. 实操演练：解一个真实的多文件、多冲突合并

纸上谈兵没什么意思，我拿一个真实项目里的合并场景来走一遍完整流程，你们可以照着模拟。

假设当前在master分支，需要把feature/login合进来。这个分支主要做了三件事：重命名了LoginService类，新增了一个TokenValidator工具类，同时修改了登录接口的返回结构。而master在分叉期间，也改了登录接口的返回结构，并且对LoginService做了一些性能优化。

执行合并：

git checkout master git merge feature/login

终端输出大概是这样：

Auto-merging src/auth/LoginService.java CONFLICT (content): Merge conflict in src/auth/LoginService.java Auto-merging src/controller/AuthController.java CONFLICT (content): Merge conflict in src/controller/AuthController.java Automatic merge failed; fix conflicts and then commit the result.

注意到：TokenValidator.java没有出现在冲突列表里，因为它是新增文件，两边没有重叠，Git 能自动处理。真正冲突的是两个被两端同时修改的文件。

第一步，查看状态：

git status

输出会是：

You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: both modified: src/auth/LoginService.java both modified: src/controller/AuthController.java

这里我要先提一句：如果你在解决冲突的过程中发现越搞越乱，想退回合并之前的状态，不要慌，执行：

git merge --abort

这个命令会把工作区恢复到git merge之前的状态。它非常安全，是我最常挂在嘴边的止损指令。不过它只适用于还没手动git add大量文件的情况；如果你已经git add了一部分，abort 也能撤销，但如果你已经手动改了很多文件并且没提交，还是先想一想。稳妥起见，暂停合并前最好备份一下自己的工作成果。

第二步，用 VSCode 打开src/auth/LoginService.java。冲突块大概长这样：

<<<<<<< HEAD public LoginResult login(String username, String password) { LoginValidator validator = new LoginValidator(); validator.validate(username, password); return legacyLoginService.login(username, password); } ======= public LoginResult login(String username, String password) { TokenValidator tokenValidator = new TokenValidator(); tokenValidator.validate(username, password); return loginService.login(username, password); } >>>>>>> feature/login

仔细读一下两边的逻辑：master这边引入了LoginValidator做校验；feature/login那边用了新建的TokenValidator，而且把legacyLoginService换成了loginService。

这两边并不是完全对立的。LoginValidator和TokenValidator的名字不同、作用可能也不同，正确做法可能是两个校验都做，或者根据业务语义确定保留哪个。loginService的替换是feature/login重构的产物，应该保留。最终合并如下：

public LoginResult login(String username, String password) { LoginValidator loginValidator = new LoginValidator(); loginValidator.validate(username, password); TokenValidator tokenValidator = new TokenValidator(); tokenValidator.validate(username, password); return loginService.login(username, password); }

我特意在这里强调：你必须在理解业务的前提下才能做出这种决策。如果只是粗暴选择任意一边，这个类的功能大概率是不完整的。

第三步，处理AuthController.java。这个文件里的冲突更简单，可能是返回结构改动的命名差异：

<<<<<<< HEAD return ResponseEntity.status(200).body(buildResultMap(loginResult)); ======= return ResponseEntity.ok(buildLoginResponse(loginResult)); >>>>>>> feature/login

这里两边都在调整统一的响应结构。看到这种情况，就要去查一下master上是否有一个buildResultMap的工具方法，feature/login上是否新增了buildLoginResponse方法。最终决定用哪边的封装后，把另一个工具方法移除，避免重复代码。

处理完这两个文件后，保存，检查冲突标记是否都消失了：

grep -r "<<<<<<<" src/

确认没有输出后，逐个添加文件：

git add src/auth/LoginService.java src/controller/AuthController.java

然后执行提交：

git commit -m "Merge branch 'feature/login' into master 保留 TokenValidator 校验及 loginService 重构 同时引入 LoginValidator 统一登录校验逻辑"

这样一个真实的合并冲突就处理完了。关键在于所有选择都是基于代码语义做的决策，而不是随意删改。

6. 常见问题与排查技巧实录

操作层面讲完了，我再把这些年积累的一些排坑经验整理一下，这些都是文档里不会写、但实际中几乎一定碰得到的东西。

6.1 大型重构类冲突：怎么避免“这边改了那边死”

有一类冲突最让人头疼：一边是全局重命名（比如方法名首字母改小写、类名统一前缀），另一边是新功能开发加入的大段代码。两边几乎每个文件都有差异，打开每个文件都一片红。

面对这种情况，不要一个个文件硬啃。我推荐的策略是：

1. 先用git log --oneline --graph --all查看两个分支的分叉点，确认对方上一次从master合并代码是什么时候；
2. 优先选择先把master合并进feature，在feature上统一解决冲突；
3. 如果涉及重命名，先看feature分支上是如何做方法调用的，把它跟master上的调用方式对齐；
4. 解决完一个文件后，用mvn compile、npm run build或者你的项目构建命令立即验证，而不是全部改完再构建；
5. 单次合并不要积压大量功能分支，尽量小步快跑，代码频繁合并，冲突规模会小很多。

之前同事遇到过一次特别极端的情况：一个前端项目重构了所有 CSS 类名，另一个分支新增了几十个页面组件。两边都是大动静，光解决 CSS 和 JSX 的冲突就花了两天。后来我们总结，解决方案就是让重命名类的重构尽量用自动化脚本一次性完成，并且别和功能分支并行太久。如果必须并行，至少每两三天同步一次。

6.2 冲突时不小心退出编辑器，或误用了错误的解决方案

有次我远程协助一位同事，他在解决冲突时误按了git checkout --ours，导致整个文件被覆盖成了master版本，对方的改动全没了。关键是他还git add并提交了合并。

这种情况不用绝望。Git 的记录在提交前都能找回来。你可以用git reflog查看所有本地分支的操作历史，找到合并冲突发生之前的那个提交哈希，然后用git checkout <commit-hash> -- <file>把那个时刻的冲突文件恢复出来重新处理。

git reflog # 找到类似 commit 914f3a2 的记录 # 恢复某个文件 git checkout 914f3a2 -- src/controller/AuthController.java git add src/controller/AuthController.java git commit

git reflog是每一个 Git 使用者都应该了解的命令。它记录了本地仓库所有引用的变动历史，相当于给你吃了颗后悔药。只要你不是真的把.git目录删了，这个命令基本都能帮你找回状态。

还有一种情况是：你解决了冲突，提交了合并，但后来发现合并结果有 bug，你想重来。这时候我不会建议你直接git revert，而是会在修复 bug 的基础上新增一个提交，因为合并提交一旦推送到公共仓库，改写它的历史会让所有人都很难受。

6.3 大文件合并冲突，谁动谁死，怎么拆解

有些项目里会存在编译产物、锁文件（package-lock.json、yarn.lock）、或者自动生成的 POJO / ORM 实体类。这些文件一旦冲突，手动改几乎等于灾难，比如前端锁文件里每个依赖的解析地址都写在同一行里，两边的 lock 版本差异可能引发大量冲突。

我的处理思路是：

• 编译产物类文件：不要解决冲突，直接用生成工具重新生成。比如 Java 的target目录可以直接不提交到版本库，如果你的仓库不小心提交了，就删掉并加入.gitignore；
• 锁文件类：保留master上的版本，然后重新执行依赖安装命令，让工具自动合并依赖。比如前端项目在冲突时可以先git checkout --theirs package-lock.json，再执行npm install或yarn install来刷新锁文件；
• 自动生成的实体类/DTO：同理，通过重新生成机制刷新，而不是手动硬改。

用git checkout --theirs或--ours单独恢复这类文件，是明确合理的取舍，因为它们的正确状态由生成器决定，不由冲突解决时的主观判断决定。

6.4 快速速查表：冲突执行动作与人对应关系

这份表是我日常协作中最常用的指令集合，建议先收藏或者打印出来放在手边。等你完全熟悉了，这些指令基本能形成肌肉记忆，就不再需要查表了。

6.5 我从大量冲突里总结的三个习惯

最后分享一下我自己从处理无数冲突里沉淀下来的三个习惯。

第一，每次主干有更新，第一时间同步到自己的分支，且越快越好。拖延只会让冲突成倍增加，代码的“新鲜度”直接影响合并成本。这跟家里垃圾要及时倒是一个道理，攒一个星期再清理，体验完全不同。

第二，在合并前先阅读对方的提交信息，大致了解分支意图。尤其当对方是一个跨多人协作的大分支时，光看代码很难判断哪些是核心改动、哪些是实验性的。有了上下文，解决冲突时你的每一个决策都会更有依据。

第三，别硬扛着解决所有冲突，该问就问。如果你的分支里有一段代码逻辑完全看不懂，随手艾特一下写这段代码的同事，直接问一句“这段逻辑在最新 master 上已经改掉了，你们分支的用法还要保留吗？”，换来的是对方立刻的解答，远比你在代码里猜来猜去要高效得多。协作开发的本质就是沟通，Git 冲突只是把沟通的需求显式化而已。

回到最初的那个观点，冲突不是 Git 在给你找麻烦，而是它在帮你把关。每次合并不顺利，多问自己一句“两边的改动为什么必须放在同一个地方”，你的代码能力和协作能力大概率就都往上涨了一点。遇到冲突，深呼吸，打开文件，一行一行读，一段一段想，然后干干净净地解决它。这，才是正确的处理流程。