大范围冲突需人工判断逻辑而非依赖自动合并——先统计并分类冲突文件，对非关键文件用--theirs/--ours快速处理，关键文件用mergetool三路比对，注意merge与rebase中ours/theirs含义相反，解决后务必验证逻辑一致性与代码完整性。
大范围冲突不是代码坏了，是 Git 在告诉你：两个分支的修改已经严重偏离，自动合并不可信——必须人工介入判断逻辑，不能靠删标记、选版本蒙混过关。
看到几十个文件标为 both modified 时先别 panic
Git 把所有有重叠修改的文件都标成冲突，但并非每个都要逐行手修。真正需要你决策的，往往是核心业务逻辑文件（比如 UserService.java、apiRoutes.ts）；而配置类、文档类、锁文件（yarn.lock、package-lock.json）通常可直接用 --theirs 或 --ours 覆盖。
- 先跑
git status --porcelain | grep "^UU" | wc -l看冲突总数，心里有数 - 用
git diff --name-only --diff-filter=U列出全部冲突文件，快速分类：哪些是代码、哪些是锁/配置/生成文件 - 对非关键文件，直接
git checkout --theirs -- <file></file>（取远端/目标分支版本）或--ours（留当前分支），然后git add - 跳过
.gitattributes、.editorconfig这类纯格式文件——它们极少含业务逻辑，冲突基本是换行符或空格差异
git mergetool 不是锦上添花，是处理 5+ 文件冲突的刚需
手动开 10 个编辑器窗口比对、删标记、保存、再 git add，出错概率极高。尤其在 JSON/YAML/Python 这类缩进或结构敏感的文件里，看串一行就可能语法报错。
- 配一个真正能用的工具：
git config --global merge.tool vscode（VS Code 自带合并视图）或meld（开源免费） - 运行
git mergetool后，它会按顺序打开每个冲突文件，显示三方内容：LOCAL（你当前分支）、BASE（共同祖先）、REMOTE（要合并进来的分支） - 不要只盯着左右两栏——中间
MERGED区才是你要编辑输出的地方；保存即自动git add，不用再手动确认 - 如果某文件只是微小改动（比如改了个字符串常量），mergetool 里点 “Accept Remote” 比手敲快 10 秒，且零出错
git checkout --ours 和 --theirs 在 merge 和 rebase 中含义相反
这是最常踩的坑：你以为在 merge 里用 --theirs 是取“对方分支”的代码，没错；但切到 rebase 场景下，--theirs 反而指“你原来的 HEAD 分支”，极易选错。
- 只在明确知道上下文是
git merge时才用这两个命令；rebase 中优先用git rebase --continue配合 mergetool - 不确定时，用
git show :2:<file></file>（BASE）、git show :1:<file></file>（OURS）、git show :3:<file></file>（THEIRS）直接看三路原始内容，比记规则更可靠 - 对关键逻辑文件，永远宁可多花 30 秒用
git diff --ours <file></file>和git diff --theirs <file></file>分别看两边改了什么，再决定怎么融合
解决完所有冲突后，git commit 前务必验证两件事
提交不是终点，而是新问题的起点。大范围冲突合并后最危险的不是语法错误，是逻辑覆盖——比如你保留了 A 分支的数据库字段名，却漏掉了 B 分支里配套的校验逻辑。
- 先跑
git diff --cached，确认暂存区里确实是你要提交的最终内容，没混入残留的冲突标记或误删的代码块 - 本地执行最小闭环验证：至少启动服务、调通一个涉及冲突模块的 API、跑通对应单元测试；别等 CI 报红才回头查
- 如果项目有 pre-commit hook 或 lint 工具，确保它们已通过——大冲突后很容易引入未格式化的代码或 console.log
- 推送到远程前，再看一眼
git log --oneline -n 5，确认最后一条是你的 merge commit，不是某个被意外带进来的旧提交
大范围冲突的本质，是两个分支长期缺乏同步导致的逻辑断层。解决它不靠技巧，靠的是看清每一处变更背后的意图；最容易被忽略的，是你在 git mergetool 里点下 “Accept Remote” 前，有没有花 5 秒读完那一段被替换掉的代码注释。
