“幽灵冲突”是指git合并未报错、无冲突标记、git status显示clean，但提交后他人代码凭空消失的行为异常现象；根本原因是手动解决冲突时仅暂存自身修改，漏加被合并分支覆盖的文件，导致未暂存的“新内容”丢失。
什么是“幽灵冲突”？它不是 Git 报错，而是行为异常
“幽灵冲突”不是 Git 官方术语，但它是团队协作中真实存在的现象：合并操作没报错、没出现 标记，<code>git status 显示 clean，但提交后发现——别人刚合入的代码不见了，或者某次 PR 的变更凭空消失。
根本原因不是 Git 搞错了，而是你执行了看似无害、实则覆盖历史的操作。最典型场景是：在 feature 分支上执行 git merge main 更新时，用 IDE（如 IntelliJ 或 VS Code）点“Apply”解决冲突，却只 git add 了自己改的文件，漏掉了其他分支已存在但被合并逻辑覆盖的文件。
Git 不会警告你“你漏加了 127 个文件”，它只认你 git add 过的路径。那些没被 add 的文件，会保留在工作区——但它们其实是目标分支（比如 main）的最新版本，而你本地 HEAD 还指向旧提交。一旦你只 commit 自己的改动，这些“新内容”就变成未追踪的脏状态，下次 git push 后，远程 main 上的对应代码就丢了。
如何快速定位已被覆盖但尚未提交的“幽灵变更”
执行完合并（尤其是有冲突后手动解决），别急着 commit。先确认工作区是否真的只包含你预期的修改：
-
git status --ignored：看有没有大量 “modified” 文件没出现在暂存区——这些就是危险信号 -
git diff --name-only HEAD：列出所有与HEAD不同但还没add的文件，这才是你真正要审的“新增变更” -
git diff --ours --no-index <file></file>和git diff --theirs --no-index <file></file>：对单个可疑文件，分别对比当前分支原始内容（--ours）和对方分支内容（--theirs），确认哪边才是你该保留的
特别注意：IDE 的“Merge into Current”按钮常默认只把冲突部分标记为 resolved，其余自动合并的文件不会高亮。你得主动检查整个工作区，而不是只盯着红标文件。
git checkout --ours 和 git checkout --theirs 的真实行为边界
这两个命令在 merge 过程中作用明确：--ours 取当前分支（HEAD）版本，--theirs 取被合并分支版本。但它们极易误用：
- 只在合并冲突状态下有效；
merge完成后或rebase中，语义会反转——rebase时--ours反而是上游分支，极易翻车 - 它们只写入工作区，不自动
git add；执行后必须手动git add <file></file>，否则仍算未解决 - 对二进制文件或图片等不可合并类型，Git 不会生成冲突标记，但
--ours/--theirs依然生效——此时你可能根本不知道自己覆盖了什么
建议：除非你清楚知道当前处于哪个上下文（merge / rebase / cherry-pick），否则优先用 git show :1:<file></file>（共同祖先）、git show :2:<file></file>（ours）、git show :3:<file></file>（theirs）来安全查看三方内容，再决定取舍。
防御代码丢失比修复更关键：合并前的三道防线
幽灵冲突本质是流程漏洞，不是技术缺陷。靠事后排查成本太高，必须前置卡控：
- 强制要求每次
git merge前运行git diff --name-only origin/main...HEAD（假设你正从main合并），确认本地分支确实只含预期变更，避免“带毒合并” - 禁止直接在长期分支（如
main、develop）上执行git merge；所有合并应通过 PR/MR 流程，由 CI 检查git diff --check和文件编码一致性 - 在 pre-commit hook 中加入
git diff --cached --quiet || (echo "ERROR: unstaged changes detected. Please git add or stash." >&2; exit 1)，堵住“只 commit 部分文件”的漏洞
最隐蔽的风险点：当你用 git merge --squash 合并多个提交时，Git 会丢弃原始 commit 元信息，如果 squash 后没仔细核对 diff，连“谁改了什么”都追溯不到——这种丢失，连 git revert 都救不回来。
