SVN合并冲突处理全攻略：从原理到实战

1. 先搞清楚：合并冲突到底是怎么发生的

1.1 冲突的本质：同一行代码的“双人舞”

先说一个很多人没想明白的事：SVN合并冲突不是软件出bug了，也不是你的操作姿势不对，而是两个改动真正“撞车”了。想象一下你和同事同时改了同一个文件里的同一行，你提交之后，他再 svn up 或者把分支合并回主干，SVN拿到两份不同的修改，不知道该听谁的，只能把问题抛给你——这就是冲突。

所以处理冲突的第一步，不是急着点选项，而是冷静下来搞清楚：这次冲突到底动了哪几行？动代码的人分别是谁？两边改动的意图分别是什么？

我曾经见过一个团队新人，遇到冲突后想都没想就点了“use mine”（使用我的版本），结果把同事重构的接口签名整个覆盖了，项目直接编译失败。后来排查了大半天才找到原因。这个教训说明：处理选项不是随机抽奖，选错了比不选更致命。

1.2 SVN能自动做哪些事，必须人工处理的又是什么

很多人以为“合并”是SVN把两个文件完全融合起来，这其实是误会。SVN的自动合并能力只限于文本文件中互不重叠的修改区域。

举个例子：你改了文件第10行，同事改了第80行，两份修改互不干扰，SVN会自动把两处改动都保留，完成一次无声无息的合并。但如果你们俩都改了第50行附近，哪怕改的具体内容不同，SVN就无法判断谁是对的，只能标记冲突，等你决策。

这里有个关键认知：冲突并不代表别人改得有问题，也不代表你改得有问题，它只是代表“两个改动在语义上可能存在矛盾，需要人类判断”。所以处理冲突的核心能力不是会点按钮，而是能读懂两边的代码，判断出哪种组合才是正确的最终结果。

1.3 三种冲突类型，先分清敌人是谁

很多教程上来就直接讲按钮，结果读者看到一堆英文选项就懵了。我建议先从冲突类型入手，因为不同冲突的处理方式完全不同。

SVN冲突分三类：

我见过最多的是文本冲突，其次是树冲突。属性和树冲突往往出现在分支合并场景中，很多人第一次遇到时完全摸不着头脑。所以下面我会分别展开讲，还会给出一套“看到冲突不慌”的处理流程图思路。

2. 处理选项逐个拆解：“我的”“他们的”到底是谁

2.1 先记住一个原则：不同的操作，主语完全不同

这是全文最重要的一块。TortoiseSVN也好，命令行也好，冲突处理选项里都会出现 mine 和 theirs 两个词，中文界面翻译成“我的”和“他们的”。但问题是：在不同操作场景下，“我”和“他们”指的对象是完全不一样的。

我整理了一张表，建议你直接收藏：

举个最常见的例子。你在trunk上改了几行代码，还没提交，这时候同事在trunk上提交了也改到同一区域的版本，你执行svn update时冲突了。此时TortoiseSVN弹窗里的“use mine”指保留你本地改的，“use theirs”指采用仓库里的新版本。

但在另一个场景下就不一样了：你在feature-branch分支上开发完，要把trunk合并过来（svn merge trunk .），这时冲突弹窗里“mine”指你分支上已有的内容，“theirs”指从trunk合并进来的内容。这和svn update场景正好打了个调。

所以，遇到冲突不要急着选，先确认你现在做的是update还是merge。这是我这几年带团队时反复强调的一句话。

2.2 accept theirs-full：什么时候无脑选择这一项

先聊 accept theirs-full，也就是完整采用“他们的”版本。很多人一看到这个选项就害怕，觉得用了别人的版本自己白改了。但实际工作中，有一个很典型的场景就适合无脑选它：

你本地文件被别人全局格式化了，或者别人做了一次大范围重构，而你在同一文件上的修改已经失去意义了。

举个真实案例：有一次团队统一把代码里的单引号改成双引号，一个同事用IDE跑了一把全项目格式化。冲突出现时，我本地只是一行注释的改动，重建意义不大，直接选theirs-full，然后用格式化后的版本重新改那一行注释。半小时搞定。

还有一个场景也适合：你的本地修改是实验性的，本来就不打算保留。比如我调试时临时加了很多System.out.println日志输出，提交分支时和主干的正式改动冲突了，这些调试代码本来就要删掉，还有必要花时间手动合并吗？直接theirs-full，拿干净版本回来，重新补正式逻辑就行。

2.3 accept mine-full：什么时候保留本地才是对的

反过来，accept mine-full是完整保留“我的”版本。适合的场景是：你确定本地的改动是当前阶段的正确结果，而对方的改动要么是旧逻辑、要么是已经被废弃的尝试。

我再举个例子。有一次我在分支里重写了一个核心函数，整个函数60行全部换血，而trunk上只是对旧函数修了一个小bug。合并时两个版本冲突，我检查了一下trunk修的bug在我的新实现里根本不存在（因为旧逻辑被推倒重写了），这种情况下选mine-full是完全正确的。

但我要泼个冷水：日常开发中，选mine-full的场景比大家想象中少得多。 更多时候冲突发生时，双方改动都有保留价值，正确的做法是手动合并。所以如果你总是习惯性点mine-full或者theirs-full，要么是你运气太好（改的文件永远只有你一个人在动），要么就是你正在丢掉别人重要的代码而不自知。

2.4 从“完整覆盖”到“逐块选择”，普通人的正确姿势

TortoiseSVN的冲突对话框里，除了“use mine full”和“use theirs full”，还有两个更精细的选项：

• Use mine text block：当前冲突块优先采用“我的”内容
• Use theirs text block：当前冲突块优先采用“他们的”内容

这两个选项说的是“当前冲突块”，意味着你可以在一个多冲突文件里，对不同的冲突块分别做选择。有些情况下这已经比“全有全无”强多了，但局限性在于：它仍然是在两个版本之间二选一，不能同时保留两边都想要的代码。

举个典型场景：同事在你负责的函数头部加了一个参数校验，你在这个函数里加了一段核心业务逻辑，冲突区域重叠。此时最好的结果是把“他们的”校验和“你的”逻辑同时保留，但任何一个text block选项都做不到。

这种情况就只能进入真正的“手动合并”。这也是我下一章要重点讲的：SVN冲突处理的主力其实不是这些选项，而是手动编辑+三路合并视图。

3. 手动合并才是日常主力

3.1 冲突文件里的“血条”怎么看

当冲突发生后，如果你用文本编辑器直接打开那个冲突文件，会看到一堆特殊的标记符号。这些符号就像代码里的“血条”，把冲突区域标得一清二楚：

code复制<<<<<<< .working
这是你本地改的内容
这里是第二行本地内容
=======
这是从仓库/源分支来的内容
这里是第二行对方内容
>>>>>>> .merge-right.r1234

各部分的含义我用表格整理一下：

手动合并的实质就是：把这堆标记连同其中你认为不需要的内容删掉，保留你认为正确的内容，最后记得把三个标记行也删干净，然后保存文件。很多人合并完忘记删标记行，一编译全报语法错误，然后就慌了。

3.2 TortoiseSVN图形化合并操作全流程

直接用文本编辑器看标记虽然能解决问题，但效率太低，尤其当冲突块多、上下文复杂时。我推荐用TortoiseSVN自带的冲突编辑器来操作。

在TortoiseSVN的冲突弹窗里点击“Edit conflict”，会打开一个三栏对比界面：

• 左侧是“theirs”（对方版本）
• 中间是“merged”（合并结果，可编辑）
• 右侧是“mine”（我的版本）

操作习惯是：从左右两边把需要的代码块“推”到中间，或者在中间直接编辑。工具栏上有几个按钮，分别对应“采用左边”“采用右边”“采用两边的全部修改”等。处理完所有冲突块后，保存并关闭编辑器，回到冲突弹窗点击“Mark as resolved”（标记为已解决）。这时文件状态就会从conflicted变为normal，你就可以正常提交了。

这里有几个实用小技巧：

1. 先按文件整体看一遍左右差异，规划好哪些块用左、哪些用右，再动手。不要看到一个块就处理一个块，容易遗漏。
2. 中间区域可以自由编辑，不只是“二选一”。我经常把左边的校验代码复制到中间，再手动调整变量名，完成既能保留校验又能融入新逻辑的定制化合并。
3. 处理完务必在本地跑一遍构建/测试再提交。合并操作是纯文本层面的，不会帮你验证语义，编译和测试才是最后的守门员。

3.3 命令行svn resolve与外部比较工具配置

如果你更喜欢命令行，SVN也提供了完整的冲突处理命令。

首先，当你执行 svn update 或 svn merge 遇到冲突时，终端会提示类似这样的信息：

code复制Summary of conflicts:
  Text conflicts: 1

被冲突的文件会处于 C 状态。此时你有两个选择：

方式一：先手动编辑文件，再用svn resolve标记解决

bash复制# 手动编辑冲突文件
vim error.c

# 确认修改无误后，标记为已解决
svn resolve --accept=working error.c

--accept=working 的意思是“以当前工作副本中的文件内容作为最终解决结果”，这是最常用也最安全的方式，因为它把决策权完全交给你自己——你先改好文件，然后只是让SVN把冲突状态去掉。

方式二：直接用非交互式参数强制选择

bash复制# 直接采用对方版本（跳过手动编辑）
svn resolve --accept=theirs-full error.c

# 直接采用本地版本
svn resolve --accept=mine-full error.c

这个方式适合你已经想清楚要“全有全无”的场景，配合脚本可以做批量处理。

关于--accept的取值，我再补全一下：

注意mine-conflict和mine-full的区别：mine-full会直接把整个文件换成你的版本，对方在文件其他位置做的修改也全部丢掉；而mine-conflict只影响冲突块，非冲突区域的合并结果仍然保留。所以如果你只是想在冲突区域偏向自己，mine-conflict是更稳妥的选择。

至于外部比较工具，TortoiseSVN默认用自带的TortoiseMerge，但你可以配置成Beyond Compare、KDiff3这些更强大的工具。配置路径在 Settings -> Diff/Merge 里，将冲突编辑器（Conflict Editor）的程序路径换成你想要的工具命令即可。我个人用Beyond Compare比较多，三路合并视图的信息密度更高，滚动对比大文件时也流畅不少。

4. 高频问题排查与避坑实录

4.1 为什么我点了“use mine”之后代码还是错的

这是很多新手问的问题。明明弹窗里点了“use mine”，打开文件一看，对方改的东西还在，或者整个文件都乱套了。

排查思路：先确认你点的到底是“use mine full”还是“use mine text block”。如果你用的是“text block”版本，它只处理当前光标所在的那一个冲突块，文件里其他冲突块仍然保留原状，需要你逐个处理。

还有一个更隐蔽的坑：TortoiseSVN的冲突弹窗每次只显示一个文件。如果你一次update了10个文件，其中5个都冲突了，你处理完第一个点“Mark as resolved”，它会自动跳到下一个冲突文件，但很多人以为已经全部解决了，直接关闭窗口去提交，结果再次报错。正确做法是处理完所有冲突文件，确认工作副本状态中没有 C 了再提交。

4.2 编译过了但别人跑不起来：被忽略的树冲突

树冲突是SVN里最容易被忽略的一类冲突。它的特点是：SVN不会像文本冲突那样弹窗提示你逐块选择，而只是把文件标记为冲突状态。

常见场景是这样的：

• 同事把 Login.java 重命名为 LoginView.java 并提交了
• 你没同步这个重命名，还在本地修改着旧的 Login.java
• 你执行 svn up，SVN发现“本地修改的文件”和“已经被重命名的文件”不是同一条时间线了，报树冲突

很多人的第一反应是“怎么又冲突了，明明没人改这个文件啊”。排查方法是在TortoiseSVN的Check for Modifications面板里看文件状态，或者用 svn status 命令，你会看到类似 C + tree conflict 的状态。

处理树冲突的一般步骤：

bash复制# 查看冲突文件详情
svn info Login.java

# 根据情况选择保留哪个文件，然后把另一个删除或移动
svn delete Login.java
# 或者
svn move Login.java LoginView.java

# 处理完后标记解决
svn resolve --accept=working Login.java

这里的核心判断是：重命名后的文件内容是不是你要的基线？如果你还要基于旧文件名修改，最好接受对方的重命名，然后再在新文件上补你的改动。

我踩过一次很深的坑：分支合并时出现树冲突，我一时偷懒，直接 svn resolve --accept=mine-full 强制解决了，结果把对方新增文件彻底排除了，合并过来的分支在编译阶段直接找不到一个重要的服务类。所以树冲突处理一定要先看文件路径变更，别图省事。

4.3 二进制文件冲突只能“二选一”吗

SVN只能合并文本内容，二进制文件（图片、压缩包、Word文档、Excel模板等）一旦冲突，不能做逐块合并，只能选择“用我的整个文件”或“用他们的整个文件”。

这个限制让很多人头疼，尤其是设计师和开发并行修改同一个原型图或者配置文件时。我要给的建议是：

1. 能用文本格式保存的，别用二进制格式。比如配置类文件尽量用.xml、.properties或.json，别用Excel作为配置源。
2. 需要频繁并行修改的二进制文件，配合svn lock使用。SVN支持文件锁，你可以对某些文件设定锁定，别人只能读不能改，从根本上杜绝冲突。
3. 真冲突了，先看版本号再选。比如设计稿冲突，一般保留最新设计稿版本，同时找设计确认版本演进。

这里也要提醒一句：svn lock不要滥用。如果只是普通Java源码文件加锁，反而会导致团队协作变慢，因为别人改文件前得先找你解锁。我一般只对资源文件、发布包这类“易碎品”加锁。

4.4 不小心关掉冲突窗口怎么办：.mine和.r前缀文件解读

冲突发生后，即使你直接关掉弹窗、或者误点了取消无关紧要——冲突文件旁边会出现几个“副产品”。这是很多初学者不知道的秘密。

在冲突文件的同一目录下，你会看到类似这样的文件：

code复制config.xml.mine
config.xml.r1245
config.xml.r1250

它们的含义是：

这几个文件是SVN留给你的“原始素材”，方便你手动恢复数据。比如你手滑把conflict文件改坏了，完全可以对比这几个副本来找回原始内容。

我曾经有一次手动合并到一半，编辑器崩溃，主文件被写入了半截内容。当时人都是麻的，后来发现.mine和.r文件都在，用Beyond Compare一对比，几分钟就把内容重新拼回来了。

主要文件处理完成后，svn resolve会把这些带有后缀的临时文件自动清理掉。所以没处理好之前，千万不要手动删除.mine或.r文件，它们是你的后悔药。

5. 如何把冲突数量降到最低

5.1 提交前先update，同步频次要跟上

处理冲突的最高境界，是压根不用处理。虽然冲突无法100%避免，但很多冲突是“笨冲突”——不是代码真正有矛盾，而是你基于过期版本改了太久。

举个典型场景：你从仓库拉了一份代码，埋头改了3天，完全没更新过，然后直接提交。这3天里如果其他同事在同一个文件上提交过多次，你的提交必然大概率冲突。这不是代码问题，是同步节奏问题。

我给自己定的规矩是：每个功能点开发完，先 svn up 一次，再本地跑一遍构建，最后提交。 如果改动量大，甚至一天同步两三次。不要觉得总同步浪费时间，多跑一次更新只需要几十秒，解决一次复杂冲突可能要搭进去一小时，这笔账很好算。

5.2 分支合并前先做一次“预演合并”

如果你负责分支合并，有一个技巧能帮你提前发现绝大部分冲突：先在一个临时工作副本上做一次“预演合并”，只观察冲突列表，不处理、不提交。

具体操作思路是：

bash复制# 复制一份干净的工作副本作为预演区
svn checkout URL-of-target-branch premerge-test

cd premerge-test
# 把源分支的改动合并进来，但只报告冲突，不实际修改
svn merge --dry-run -r 起始版本号:结束版本号 URL-of-source-branch

--dry-run 参数的意思是“只计算合并结果，不写回文件”。它会把哪些文件会冲突、哪些会自动合并列给你看。拿到这个清单后，你可以提前通知相关同事，让对应文件的主人预先做好协调。

等到真正合并时，我会把预演阶段用的“一次性工作副本”直接删掉，重新拉一个干净的副本执行合并。这么做的好处是：如果合并过程中你发现自己把文件改乱了，可以随时扔掉重来，不影响正式工作副本。

5.3 用svn:ignore和目录锁避免无谓冲突

这类冲突最让人无语：两个人改了同一个文件，但改的其实是IDE自动生成的临时文件。解决方式不是练好合并技术，而是从一开始就别让这些文件进版本库。

svn:ignore 属性可以配置忽略规则，类似Git的.gitignore。设置方式：

bash复制svn propset svn:ignore -F .svnignore .

.svnignore文件里写：

bash复制target/
*.class
.idea/
*.iml
*.log

这样IDE生成的临时文件不会进入SVN管理，自然也不会因为“本地生成了新文件、别人也生成了同名文件”触发树冲突。

另外，对于确实需要多人协作但又不适合频繁合并的目录，比如数据库初始化脚本、发布配置文件，可以通过svn lock控制写权限。锁定的文件别人想编辑时会提示无法提交，必须等你解锁。这能大幅降低特定目录的冲突概率。

最后聊几句我的习惯

处理SVN冲突这几年，我最深的体会是：冲突本身不可怕，可怕的是在没弄清楚双方改动内容的情况下乱选选项。 我见过太多事故，都是因为“赶时间点了use mine”或者“看都没看直接use theirs”。所以我现在的流程固定是：冲突弹窗出来以后，先不急着点任何选项，而是把冲突文件用比较工具打开，左右各看一遍，确认两边改了什么，再决定是全用、全不用，还是逐块合并。整个过程多花三五分钟，但能避免后续几小时的返工。

最后再分享一个小技巧：处理完冲突后，提交信息里明确写上“merge conflict resolved”，这样翻看历史日志时，能快速定位每个冲突的处理节点。 配合SVN的版本号日志，整个项目的变更脉络会清晰很多。希望这篇内容能帮你在遇到SVN合并冲突时，不再对着弹窗发懵。