git分支合并后代码“丢失”通常因revert污染合并基础导致，非真删除；可通过git reflog、二次revert或重置合并上下文找回，本质是git未真正删除代码。
Git分支合并后代码“丢失”，90%的情况不是真丢了，而是被合并策略或历史记录机制过滤掉了——直接查 git reflog 或 git log --all --grep=xxx 往往比重写代码快得多。
为什么 merge 后 git status 显示“Already up to date”但文件没了
这是 revert 合并提交后最典型的假性丢失。Git 认为：你之前已经把 feature 分支的变更“处理过”了（哪怕是以 revert 方式抵消），所以再次 git merge feature 时，它只对比「feature 分支新增的、master 还没见过的提交」。而 revert 提交本身会污染合并基础（merge base），导致 Git 错判哪些变更属于“新内容”。
- 执行
git merge-base master feature，看输出是不是指向一个很老的提交（比如 revert 前的 merge commit） - 用
git log --oneline --graph --all观察分支拓扑，常会发现 master 上有一条孤零零的 revert 提交，像一道墙隔开了后续变更 - 别信
git diff master...feature的空输出——它默认走的是对称差（symmetric difference），容易漏掉被 revert “标记过”的提交
找回代码的三种实操路径
按风险和适用场景排序，不推荐盲目 reset：
-
最快应急：从原分支直接检出文件，
git checkout feature/shopping-cart-v1 -- src/main/java/com/demo/controller/，再git add+git commit。适合单人修复、无并发修改的场景 -
保留历史且可追溯：对 revert 提交再做一次 revert，即
git revert <revert-commit-hash></revert-commit-hash>。这会生成一个“正向补丁”，让原始功能重新进入历史流，后续 merge 就能正常识别 -
彻底重置合并上下文：在 master 上
git reset --hard <pre class="brush:php;toolbar:false;"></pre>，然后重新 merge feature（注意：会丢弃 revert 之后的所有提交，仅限本地未推送或团队同步确认后操作）
合并时文件被批量删除（如 delete mode 100644）
这不是 Git bug，而是三方合并算法的必然结果：当 Git 发现某个文件在当前分支被删除、在目标分支被修改，它会默认采用“删除”动作——因为删除是更确定的操作，修改可能含冲突。
- 检查
git status输出里是否有deleted by us或deleted by them标记，这说明 Git 已经帮你做了取舍 - 用
git show <merge-commit>:path/to/file</merge-commit>查看该文件在 merge commit 中的实际内容，确认是真删了还是只是没出现在工作区 - 预防方法：合并前先
git merge origin/main --no-commit，手动git checkout --ours或--theirs指定保留哪边，再git commit
最容易被忽略的底层事实
Git 从不真正“删除”代码，只要那个 commit 还在 reflog 里（默认保留 90 天），就能找回来。真正危险的是：git gc 自动清理、git push --force 覆盖远程引用、或者本地执行了 git clean -fdx。遇到“消失”，第一反应不该是重写，而是跑三行命令：
git reflog --date=iso<br>git fsck --unreachable<br>git log --all --grep="cart" --oneline
很多所谓“丢失”，其实就卡在没意识到 revert 提交本身也是个有效 commit，它后面跟着的才是你要的东西。
