执行 git pull 和 stash pop 后为什么能精确恢复代码状态？

git pull 配合 stash pop 能恢复代码状态，是因为 stash 把本地修改存成了独立的提交对象，pull 完成后再把修改应用回来，但如果有冲突需要手动处理。

先说结论：这套流程能恢复代码是因为 stash 独立保存了你的修改，但恢复是否成功取决于修改内容是否与拉取的代码冲突。

命令速用版

git stash
git pull origin main
git stash pop

如果有多条 stash 记录，可以指定恢复某一条：

git stash list
git stash pop stash@{0}

git stash 的本质是把当前工作区和暂存区的修改打包成一个特殊的提交对象，存到 refs/stash 引用下。这个提交对象包含三部分信息：工作区修改内容、暂存区内容、以及基础提交的引用。

当你执行 git pull 时，Git 会拉取远程代码并尝试合并到当前分支。因为 stash 已经把本地修改独立保存了，工作区是干净的，所以 pull 不会因为本地修改而失败。

执行 git stash pop 时，Git 会从 stash 栈中取出最近一次保存的修改，尝试应用到当前工作区。如果应用成功，该 stash 记录会被自动删除；如果发生冲突，stash 记录会保留，让你有机会重新处理。

第一步：保存本地修改

git stash save "临时保存开发中的功能"

执行后可以用 git stash list 确认是否保存成功，会看到类似 stash@{0}: On main: 临时保存开发中的功能的记录。

第二步：拉取远程代码

git pull origin main

此时工作区是干净的，pull 不会因为本地修改而报错。如果 pull 过程中有合并冲突，需要先解决冲突并完成合并。

第三步：恢复暂存的修改

git stash pop

如果恢复顺利，命令会输出类似"Dropped refs/stash@{0}"的信息，表示 stash 记录已删除。如果有冲突，Git 会提示冲突文件，此时 stash 记录不会删除。

第四步：处理冲突（如果有）

如果 pop 时出现冲突，打开冲突文件手动解决，然后执行：

git add 冲突文件路径
git stash drop

确认修改无误后再提交。

执行完上述流程后，用以下命令检查状态：

git status
git diff
git stash list

git status 应该显示你恢复的修改文件，git diff 可以看到具体改动内容，git stash list 中对应的 stash 记录应该已消失（如果 pop 成功）。

如果想确认某个文件是否恢复到位，可以直接打开文件检查关键代码段，或者用 git diff HEAD 对比当前工作区与最新提交的差异。

坑 1：pop 后 stash 记录消失但代码没恢复

这通常是因为 pop 时发生了冲突，Git 中止了操作但提示不够明显。检查 git status 看是否有未合并的文件，冲突文件里会有<<<<<<<这样的标记。

坑 2：多次 stash 后恢复错版本

stash 用栈管理，默认 pop 恢复的是最近一条（stash@{0}）。如果有多条记录，先用 git stash list 确认编号，再用 git stash pop stash@{n} 指定恢复。

坑 3：误删 stash 后无法找回

stash 记录不在 reflog 中长期保留，一旦 drop 或删除就很难恢复。重要的修改建议先用 git stash apply 测试恢复效果，确认无误再用 pop。

坑 4：未跟踪文件没被保存

默认 git stash 只保存已跟踪文件的修改。如果需要保存新创建但未 add 的文件，要用 git stash -u 或 git stash `--include-untracked`。