1. 从“合并地狱”到优雅解决理解冲突的本质在团队协作开发中Git 合并或变基时遇到冲突几乎是每个开发者都会经历的“必修课”。面对满屏的 HEAD、和 feature-branch标记很多人的第一反应是手动逐行比对、判断、修改这个过程不仅耗时耗力而且容易出错尤其是在处理大型文件或复杂逻辑时堪称“合并地狱”。但 Git 其实为我们提供了更高效、更“武断”的解决方案--ours和--theirs策略。这两个选项并非魔法它们代表了一种明确的决策逻辑当冲突发生时我们不再纠结于每一行代码的细节而是直接告诉 Git“在本次合并中无条件采用‘我方’ours的版本”或“无条件采用‘对方’theirs的版本”。这听起来很粗暴但在许多特定场景下它却是最优雅、最正确的选择。理解并善用它们能让你从繁琐的冲突解决中解放出来将精力集中在更有价值的开发任务上。关键在于你需要清楚地知道“ours”和“theirs”在 Git 的不同操作如merge、rebase、checkout中具体指代谁以及如何精准地使用它们。这不仅仅是记住两个命令参数更是对 Git 工作流和版本控制哲学的一次深入理解。2. “Ours”与“Theirs”的身份之谜上下文决定一切这是使用--ours和--theirs时最核心、也最容易混淆的概念。它们的指代并非固定不变而是完全依赖于你正在执行的 Git 命令的上下文。用错了上下文你的选择就会南辕北辙。2.1 在git merge操作中假设我们有一个主分支main和一个功能分支feature。当前我们在main分支上执行git merge feature意图将feature的改动合并进来。--ours: 指代当前所在分支即main分支的版本。因为是我们main主动去合并别人feature。--theirs: 指代被合并的分支即feature分支的版本。因为“他们”是我们要合并进来的对象。记忆口诀merge时“我”当前分支是“ours”“来者”被合并分支是“theirs”。2.2 在git rebase操作中这是一个常见的混淆点。假设我们仍在feature分支上执行git rebase main意图将main分支的新提交作为我们新工作的基础。--ours: 指代上游分支即main分支的版本。在变基过程中Git 会依次将我们的提交在feature上应用到main的顶端。当发生冲突时冲突是在“将我们的补丁打到他们的代码上”时产生的。此时“他们的代码”即main是基底所以是--ours。--theirs: 指代正在被移动的提交即我们feature分支上原本的提交版本。因为“他们”是我们的旧提交正试图被应用到新的基底上。记忆口诀rebase时“新家”上游分支是“ours”“搬家者”当前分支的旧提交是“theirs”。这与merge的指代正好相反这是很多开发者踩坑的地方。2.3 在git checkout操作中这个命令用于从索引暂存区检出特定版本的文件到工作区常用于快速解决冲突。git checkout --ours file: 用当前分支的版本覆盖工作区的冲突文件即清除冲突标记文件内容完全变成当前分支的样子。git checkout --theirs file: 用对方分支的版本覆盖工作区的冲突文件。这里的“ours”和“theirs”的指代逻辑与git merge保持一致非常直观。它是解决单个文件冲突最快的方式。注意checkout的这两个选项仅在有冲突的文件上生效。如果文件没有冲突标记使用它们不会有任何效果。为了更清晰地对比我们可以用下表总结操作场景命令示例--ours指代--theirs指代使用场景举例合并 (Merge)git merge feature当前分支 (main)被合并分支 (feature)决定在合并冲突中完全保留主干的修改。变基 (Rebase)git rebase main上游分支 (main)正在变基的旧提交 (feature)在变基冲突中决定完全采用目标分支的代码作为新基底。检出文件 (Checkout)git checkout --ours file.txt当前分支版本对方分支版本快速放弃对某个冲突文件的修改直接采用自己分支的版本。理解这张表你就掌握了--ours和--theirs的“地图”不会再迷失方向。3. 实战演练在合并中一键解决冲突理论清晰后我们进入实战。假设你正在main分支上开发一个核心模块同时同事在feature/ui-redesign分支上重构了前端界面。现在你需要将他的改动合并进来但合并后产生了大量关于样式文件和配置文件的冲突。你评估后认为对于config.json这个配置文件必须完全保留main分支的版本因为包含了你刚配好的生产环境参数而对于styles/目录下的所有 CSS 文件则可以完全采用同事的新设计。3.1 步骤一发起合并并遭遇冲突首先确保你在main分支然后尝试合并。git checkout main git merge feature/ui-redesign不出所料控制台输出提示存在冲突合并过程暂停。3.2 步骤二针对特定文件使用策略现在我们使用checkout命令来快速解决特定文件的冲突。保留“我方”版本对于config.json我们决定无条件采用main分支的版本。git checkout --ours config.json这条命令执行后工作区中的config.json文件会立刻变回main分支上的原始内容所有冲突标记消失。Git 会将该文件标记为“已解决”。采用“对方”版本对于整个styles/目录我们决定无条件采用feature/ui-redesign分支的版本。git checkout --theirs styles/这条命令会递归地将styles/目录下所有有冲突的文件都替换成feature/ui-redesign分支上的版本。3.3 步骤三完成合并在解决了所有你决定用策略处理的文件冲突后你可能还有一些文件需要手动合并。处理完所有冲突文件后使用git status查看应该只剩下需要被添加到暂存区的文件。将解决后的文件添加到暂存区并提交合并结果。git add . git commit -m “merge feature/ui-redesign: 保留main的config采用feature的样式”至此一次有选择性的、高效的合并冲突解决就完成了。你无需打开config.json和几十个 CSS 文件去逐行比对节省了大量时间。实操心得git checkout --ours/theirs是就地覆盖工作区文件。在执行前如果你对当前工作区的冲突版本有任何想保留的修改尽管可能性不大请先做好备份。一个更安全的方法是先使用git diff对比--ours和--theirs的版本确认无误后再执行覆盖。4. 高级策略合并时全局使用“Ours”或“Theirs”上面的方法是解决部分文件的冲突。但有些时候我们的策略是全局性的。例如当合并一个已经废弃的分支或者进行一次“假合并”仅为了记录合并历史但不引入任何代码变更时我们需要在合并命令中直接指定策略。4.1-X选项指定合并策略的选项Git 的merge命令支持-X注意是大写 X选项来为默认的“递归合并”策略传递参数。完全采用我方版本git merge -X ours feature-branch这条命令告诉 Git在合并feature-branch时如果遇到任何冲突全部以当前分支ours的版本为准。feature-branch中那些不冲突的改动仍然会被合并进来。完全采用对方版本git merge -X theirs feature-branch这条命令则相反所有冲突都以feature-branchtheirs的版本为准。重要提示-X ours/theirs与后文将提到的--strategy-option是等价的例如git merge -s recursive -X ours。4.2-s策略我们的“核武器”——ours合并策略Git 还有一个更“绝”的合并策略ours。注意这是一个独立的合并策略-s ours而不是一个选项-X ours。git merge -s ours feature-branch这个命令的威力在于它会产生一个合并提交但这个合并提交的内容与当前分支在合并前的状态完全一样被合并分支feature-branch的任何改动都不会被引入。它解决了什么问题假设你的团队有一个长期存在的legacy分支它已经不再活跃但为了保持历史记录的完整性你需要将它合并到main分支并关闭。直接合并可能会带来大量冲突和垃圾代码。使用-s ours可以“假装”合并了它在历史图上创建一条清晰的合并路径表明legacy分支的工作已经结束并被main分支所接纳但实际上没有引入任何它的代码变更。与-X ours的关键区别-X ours解决冲突时全用我的但不冲突的改动依然会进来。-s ours整个合并过程都忽略对方的任何改动结果就是我的代码原封不动。踩坑记录 我曾经在需要完全覆盖另一个分支内容时错误地使用了-s ours结果导致对方的有效变更全部丢失。正确的做法应该是先git merge -X theirs如果冲突全用对方的或者更常见的直接使用git checkout feature-branch -- .来覆盖所有文件。务必分清“忽略对方所有内容”-s ours和“冲突时采用对方版本”-X theirs的天壤之别。5. 在变基中谨慎使用逻辑反转的陷阱变基中的--ours和--theirs是重灾区。让我们重现一个经典场景你在feature分支上基于旧的main提交了工作。现在main分支已经前进了很多你需要通过git rebase main来让你的工作基于最新的main。变基过程中Git 会尝试将你的每一个提交补丁应用到新的main上一旦某个补丁应用失败冲突变基就会暂停。此时git status可能会显示冲突。但请注意此时工作区的状态是文件内容正处于“将你的旧提交应用到新main时失败”的中间状态。如果你想放弃当前这个冲突的提交比如这个提交只是修改了注释不再重要完全采用新main的代码然后继续变基后面的提交你应该怎么做由于在rebase上下文中--ours指代上游分支 (main)--theirs指代你的旧提交。所以要采用main的代码放弃当前冲突的提交git checkout --ours .要采用你旧提交的代码保留当前冲突的提交git checkout --theirs .这里极其容易搞反因为直觉上我们觉得正在feature分支上操作“我”应该是ours。但 Git 的逻辑是围绕“补丁应用”建立的。一个可靠的记忆方法是在rebase暂停时使用git rebase --show-current-patch或查看状态提示明确当前正在应用哪个旧提交。或者更稳妥的做法是使用git diff --name-status --diff-filterU列出所有冲突文件。对每个文件用git diff HEAD:file main:file和git diff HEAD:file feature-old-commit:file来具体查看“当前基底版本”和“我的旧版本”的差异再决定用checkout --ours还是--theirs。处理完冲突后执行git add .和git rebase --continue。警告在复杂的变基中盲目使用--ours/--theirs可能导致一系列提交的语义被破坏。变基的本质是重写历史任何冲突解决都需格外小心最好在解决后运行测试确保功能正常。6. 自动化与脚本批量处理的智慧当冲突文件非常多时手动一个个checkout效率低下。我们可以利用 Shell 命令进行批量处理。场景合并后所有*.md文档文件冲突决定全部采用对方版本所有*.java源文件冲突决定全部采用我方版本。# 列出所有冲突的 .md 文件并对每个采用 --theirs 版本 git diff --name-only --diff-filterU | grep \.md$ | xargs -I {} git checkout --theirs {} # 列出所有冲突的 .java 文件并对每个采用 --ours 版本 git diff --name-only --diff-filterU | grep \.java$ | xargs -I {} git checkout --ours {}命令解析git diff --name-only --diff-filterU列出所有处于未合并冲突Unmerged状态的文件名。grep \.md$过滤出以.md结尾的文件。xargs -I {} git checkout --theirs {}将前面列出的每个文件名代入到{}的位置执行git checkout --theirs命令。你也可以将常用的策略写成 Git 别名放在~/.gitconfig中[alias] resolve-ours !f() { git diff --name-only --diff-filterU | xargs -I {} git checkout --ours {}; }; f resolve-theirs !f() { git diff --name-only --diff-filterU | xargs -I {} git checkout --theirs {}; }; f这样合并冲突后只需执行git resolve-ours就能一键采用我方版本解决所有冲突非常高效。注意事项 批量操作是一把双刃剑。务必在操作前先运行git diff --name-only --diff-filterU确认文件列表是否符合预期。最好能先在一个干净的分支上测试你的批量命令或者至少先对少数几个文件进行试运行。一旦批量执行再想恢复混合的冲突状态就非常困难了。7. 决策框架何时该用何时不该用--ours和--theirs并非银弹它们是一种“策略性放弃思考”的工具。使用得当能提升效率滥用则可能导致 bug。以下是一个简单的决策框架应该使用--ours/--theirs的场景配置文件冲突例如数据库连接字符串、服务器地址、特性开关等环境相关配置。通常你很清楚哪个分支的配置是当前需要的如main是生产配置dev是开发配置。自动生成的文件如package-lock.json、yarn.lock、composer.lock或编译产物dist/,build/。这些文件应该根据解决冲突后的实际依赖重新生成而不是手动合并。直接采用一方版本后再运行npm install或构建命令重新生成是最佳实践。合并已被接受的重写当一个分支如feature对某个模块进行了彻底的重构并已被评审通过而另一个分支如hotfix只在该模块的旧版本上做了小修改。合并时对于该模块的文件直接采用feature分支--theirs的版本是合理的因为hotfix的修改可能已不适用。清理或关闭分支使用git merge -s ours来记录一个已完结分支的历史而不引入其变更。绝对不应该使用--ours/--theirs的场景业务逻辑核心代码冲突对于.java,.py,.js等源文件冲突往往意味着两边对同一段逻辑有不同的修改。盲目选择一方可能会丢失另一方的功能增强或 bug 修复导致运行时错误。这类冲突必须手动仔细检查并合并。你不理解冲突内容时如果你不清楚两个版本差异的具体含义那么使用策略就是赌博。正确的做法是拉上相关代码的作者一起 Review 冲突。需要融合双方改动时有时冲突的双方修改是互补的例如一方增加了参数校验另一方修改了内部算法。这时你需要手动创建一个融合了双方优点的新版本。我的个人经验法则是对于文本文件代码、文档默认手动合并对于二进制文件图片、PDF或机器生成的锁定文件优先考虑使用策略。在执行checkout --ours/theirs前花几秒钟用git diff --no-index --ours --theirs 冲突文件快速浏览一下差异范围这个命令可以并排显示两个版本的差异能帮你快速做出是否适合使用策略的判断。记住工具是为人服务的清晰的意图和审慎的判断永远比工具本身更重要。