解决冲突后同事代码丢失，根本原因是apply仅清除冲突标记但未完成合并，git status和git diff head...merge_head可识别遗漏变更，合并后须用git log --cherry-pick验证提交完整性。
git merge --abort 后先别急着重试
合并冲突解决完却丢了同事的代码，往往不是解决得不对，而是没意识到“解决冲突”不等于“合并完成”。IDEA 点 Apply、VSCode 点 Accept Current Change，只是把标记删了、文件改了，但 Git 还卡在 MERGING 状态。此时如果只选自己改的文件 git add 再 git commit，Git 就会按你暂存的文件生成提交——没暂存的改动（比如主分支上别人新增的函数）就彻底被跳过了。
所以第一步永远是：git status 看清楚哪些文件标着 unmerged，哪些只是 modified；再用 git diff --cached 检查即将提交的内容是否包含了所有应带入的变更。漏掉的往往不是冲突块，而是你根本没打开看过的、没冲突但被覆盖的文件。
用 git diff HEAD...MERGE_HEAD 对比三方内容
Git 合并本质是三方比较：共同祖先 + 当前分支 + 待合入分支。直接看 git diff 或 VSCode 的双栏对比，只能看到两方差异，容易忽略“这个文件在祖先里本来就有，现在被另一方删了或重写了”的情况。
真正要检查是否遗漏关键代码，得用：
git diff HEAD...MERGE_HEAD
这条命令会展示“待合入分支相对于当前分支的净变更”，也就是你这次合并**实际要带进来什么**。重点关注：
- 是否有大量
-行（表示待合入分支删掉了当前分支已有的代码） - 是否有新增但你完全没碰过的文件出现在列表里
- 配置文件、路由表、API 定义等共享文件是否被整块替换
VSCode 里别信“Compare Branches”的默认方向
VSCode 的 Git: Compare Branches 功能，默认左侧是当前分支，右侧是目标分支。但如果你站在 feature 分支去对比 main，看到的是“feature 相对于 main 多了什么”，这跟你要执行的“把 main 合进 feature”完全相反。
正确做法是：
- 先
git switch main，再git merge feature（即站在目标分支，合来源分支） - 或者在 VSCode 中手动指定：左侧选
main（基准），右侧选feature（待合入），才能看清你要带进来的到底是什么 - 特别注意那些没标冲突、但颜色变灰的行——那是被待合入分支删除的内容，极易被忽略
合并后立刻跑 git log --cherry-pick --oneline
合并提交完成后，马上验证有没有“该来没来”的提交：
git log --cherry-pick --oneline main...feature
这条命令列出所有在 feature 上存在、但在 main 上缺失的提交。如果输出为空，说明 feature 的全部变更确实已进入 main；如果还有提交，就说明合并过程漏掉了某些 commit（常见于使用 git merge --squash 或手动生成新 commit 而非真正的三方合并）。
更关键的是，它能帮你定位到具体哪次提交里的代码不见了——比如输出里还剩 abc1234 feat: add user profile api，那就直接去查这个 commit 里修改的文件，逐个确认是否真的在合并后的代码里。
真正危险的不是冲突本身，而是你以为解决了冲突，其实只是把别人的代码从工作区悄悄抹掉了。每次合并后，花 30 秒跑一遍 git diff HEAD...MERGE_HEAD 和 git log --cherry-pick，比事后翻 reflog 找回代码快得多。
