冲突时应先用git status定位文件，手动编辑解决冲突标记，再git add并commit；若想避免冲突，改用git stash apply代替pop，它只恢复不删除stash，更安全可控。
git stash pop 报 CONFLICT 怎么办
直接用 git stash pop 恢复暂存时出现冲突，说明你当前分支的文件和 stash 里保存的改动在相同位置有不同修改。这不是错误，Git 只是把决定权交还给你——它不敢自动覆盖或丢弃任何一方的改动。
常见现象包括：CONFLICT (content)、CONFLICT (modify/delete)，打开对应文件能看到 和 <code>>>>>>> stash@{0} 这类标记。
- 先别急着
git reset --hard，那会丢掉 stash 里的改动（git stash记录还在，但工作区改没了） - 用
git status看哪些文件冲突，逐个打开处理 - 手动删掉冲突标记，保留需要的逻辑（比如保留你刚写的函数体，而不是覆盖成旧版本）
- 改完后
git add这些文件，再git commit或继续后续操作
想恢复但不触发冲突？试试 git stash apply
git stash pop 是“恢复 + 删除 stash”，一旦冲突中断，stash 就没了；而 git stash apply 只恢复不删除，失败了也能重来。
适合场景：不确定当前分支是否干净、担心冲突后手忙脚乱、或者想先预览 stash 内容再决定怎么合并。
-
git stash apply stash@{0}：恢复最近一次暂存 -
git stash apply stash@{1}：恢复倒数第二次（用git stash list确认索引） - 如果应用后有冲突，
git stash drop stash@{0}手动删掉已用过的 stash - 加
--index参数可保留原暂存区状态（比如之前git add过的文件仍处于暂存态）
恢复前先同步远端代码，避免白忙活
很多人 pop 失败，根本原因是：stash 是基于旧提交保存的，而当前分支已经往前走了很多步（比如别人 push 了新提交）。这时直接 pop，Git 比较的是“旧 base vs 新 HEAD vs stash”，冲突概率陡增。
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
更稳妥的做法是：先让当前分支跟上远端，再恢复 stash。
- 切到目标分支后，先
git fetch origin拉取最新引用 - 用
git rebase origin/main（或对应主干分支）把本地提交“挪”到最新 base 上 - 再
git stash apply，此时冲突通常更少、更局部 - 如果 rebase 过程中也有冲突，优先解决 rebase 冲突，再处理 stash 冲突
stash 冲突后误操作导致代码丢失怎么办
最怕的是冲突没解决完就 git reset --hard，结果 stash 没丢、但工作区改写回去了——你以为丢了，其实还在栈里。
关键点：只要没执行 git stash drop 或 git stash clear，stash 就一直存在本地。
-
git stash list一定能看见记录，哪怕你已经pop过一次失败 -
git stash show -p stash@{0}可预览具体改了哪些行 - 如果工作区被
reset搞乱了，直接git stash apply stash@{0}再来一遍 - 实在找不到，
git fsck --lost-found有时能捞回 dangling commit（但别依赖这个）
真正容易被忽略的是：stash 不跨仓库、不推送到远端，且每次 git stash 都会生成新对象。多人协作时，别指望队友能帮你找回你本地的 stash —— 它只属于你当前这台机器上的那个 Git 目录。
