Sublime Text 本身不参与 Git 冲突检测，所谓“误判”实为 Git CLI 在 rebase 等操作中真实判定的冲突；其根源在于 Git 的三路合并逻辑对格式变更、分叉点偏移或 merge 驱动忽略等场景的敏感响应，而非 Sublime 主动识别错误。
Sublime Text 本身不参与 Git 冲突检测，误判根源在 Git CLI 行为
Sublime Text 不解析冲突标记、不介入 Git 的合并逻辑，所谓“频繁触发检测误判”，其实是 Git 在 rebase 过程中真实产生了冲突（或 Git 认为有冲突），而 Sublime Text 的插件（如 GitSavvy）只是被动显示了 Git 的输出。常见假象是：文件内容明明没重叠，却报 CONFLICT (content): Merge conflict in xxx——这说明 Git 已判定为冲突，不是 Sublime “误判”，而是 Git 的三路比较结果本身就有歧义。
rebase 中“无修改却冲突”的三大真实原因
这类现象多见于长期未同步的 feature 分支 rebase 到主干时，本质是 Git 的祖先追溯失效或历史变更被错误归因：
-
git rebase默认使用ort合并策略（Git 2.34+），对空行、缩进、注释变动更敏感；若原始提交含格式化改动（如 Prettier 自动加空行），Git 可能将无关变更与业务逻辑混为同一“修改块” - 分支分叉点（
base）选取错误：比如用git rebase main时，当前main已前进多步，但你的 feature 分支仍基于旧版main提交，Git 会把“旧 main → 新 main”的所有变更都当作待应用 patch，稍有重叠即冲突 -
.gitattributes中定义了merge=ours或自定义合并驱动，但rebase默认忽略该配置——它只走底层三路合并，不读取 merge 驱动策略
GitSavvy 插件在 rebase 中的局限与绕过方式
GitSavvy 能发起 git rebase，但无法干预其内部比较逻辑，也不提供跳过特定冲突的交互入口。遇到“疑似误判”时，硬扛手动解决效率极低，应优先从 Git 层压制干扰：
- 改用
git rebase -X ignore-space-change -X ignore-whitespace，抑制空格/缩进类噪声 - 指定精确基点：
git rebase --onto main $(git merge-base main feature/login) feature/login，避免 Git 错选分叉祖先 - 临时禁用格式化工具影响：rebase 前运行
git config --local core.autocrlf false（Windows）或git config --local core.whitespace nowarn（防换行符干扰） - 若确认是 Git 误判且无法规避，用
git rebase --skip跳过问题提交（仅限该提交确实无实质变更）
Sublime Merge 无法绕过 Git 的冲突判定
即使唤起 Sublime Merge 执行 git mergetool，它也只是可视化呈现 Git 已判定的冲突块——界面里看不到的“非冲突区域”，Git 早已自动合并；界面上看到的每一个冲突块，都是 Git 三路比较后明确标记的 区段。试图在 Sublime Merge 中“强行接受某侧”来“消除误判”，只会掩盖真实问题：Git 仍会在 <code>git rebase --continue 时校验合并结果的语义一致性，若跳过本应处理的逻辑冲突，后续 commit 可能编译失败或行为异常。
真正要解决的不是“怎么让 Sublime 不报错”，而是“为什么 Git 认为这里必须人工介入”。检查 git show HEAD^:path/to/file 和 git show main:path/to/file 的原始版本，比盯着 Sublime 界面更能定位误判源头。
