2026/9/17 7:08:12
FEATURED · 精选文章 
1. 从底层机制看:一个写进 .git,一个只留在 IDE 里先说结论:很多人以为 IDEA 的 Shelve 和 Git 的 Stash 只是同一个功能的两套皮,点哪个都一样。这个认知在实际项目里迟早会咬你一口。它们从存储位置、数据格式、生命周期到恢复方式,几乎没有一处是重合的。想搞清楚该用哪个,得先看它们各自往磁盘上写了什么。1.1 Git Stash 本质是一次隐藏的多方提交敲下git stash的那一刻,Git 干的并不是把文件挪到某个角落这么简单。它实际上做了三件事:先把当前工作区的改动打包成一个 commit 对象,再把暂存区(index)的状态打包成另一个 commit 对象,然后把工作区和暂存区都重置回 HEAD 的干净状态。这个打包出来的 commit 不挂在任何分支上,而是由.git/refs/stash这个引用指向,同时在.git/logs/refs/stash里留下一条 reflog 记录。正因为它是货真价实的 commit 对象,git show stash{0}、git diff stash{0}这类命令全都能用,甚至可以把它打成补丁文件发给同事。stash{0}这个写法本身就是 reflog 语法——{0}是最近一次,{1}往前推一次。这同时也解释了另一个常见疑问:为什么git log里看不到你 stash 的东西?因为它压根不在当前分支的提交链上,只是被一个特殊引用拽着,不让垃圾回收把它清掉。还有一点特别容易被忽略:stash 默认不收未跟踪文件(untracked)和被忽略文件(ignored),要额外加-u/--include-untracked或者-a/--all。为什么默认不收?因为未跟踪文件里往往混着构建产物、临时日志、本地私有配置,一股脑塞进去只会让下次恢复变成一个大型灾难现场。这是设计上的取舍,不是 bug。1.2 IDEA Shelve 只干一件事:把 diff 搬进 IDE 的目录IDEA 的 Shelve 走的是完全另一条路。它不碰.git目录里的任何东西——不创建 commit、不动 HEAD、不写 reflog、不留引用。它做的事情是把当前 changelist 里选中文件的 diff(补丁)序列化成一个文件,存到 IDE 配置目录下的shelf文件夹里,然后把工作区中这些改动撤掉,让你的代码回到看起来干净的状态。这个路径大致是这样:Windows 上在%APPDATA%\JetBrains\IntelliJIdea版本号\shelf,macOS 上在~/Library/Application Support/JetBrains/IntelliJIdea版本号/shelf,Linux 上在~/.config/JetBrains/IntelliJIdea版本号/shelf。更早的版本曾经把它放在项目的.idea/shelf目录里,所以你在老项目里翻到这个文件夹也别意外。以 2023.x 版本为例,目录名里的版本号会跟着 IDE 升级变,不同版本的具体位置也略有出入,但大方向就是跟着 IDE 配置走,不跟着仓库走。这意味着什么?shelve 出来的东西只有 IntelliJ 系 IDE 认,命令行 Git 对它一无所知。你换一台电脑、重装一次 IDE、手滑清掉配置目录,shelf 就没了。反过来看,它也绝不会污染任何人的 Git 历史:不会出现在git log里,不会跟着 push 跑到远端,同事在仓库里永远看不到你本地存过什么。这种彻底的私有性在某些场景下是优点,在另一些场景下是致命的缺点。另一个关键差异是粒度。shelve 以 changelist 为单位,你可以在Shelve Changes对话框里只勾选某几个文件,甚至只 shelve 单个文件里的某几个改动块(hunk)。stash 当然也能做到——git stash push -p支持交互式挑选 hunk——但纯命令行做这件事的手感,用过的同学心里都有数。1.3 一张表把两者的关键属性摆在一起对比维度Git StashIDEA Shelve底层形态真实的 commit 对象 reflogIDE 私有的补丁文件存储位置仓库内.git目录IDE 配置目录下的 shelf 文件夹是否进 Git 历史不进分支历史,但进 reflog完全不进 Git命令行能否识别能,git stash list全都能操作不能,只有 IDE 认换电脑能否恢复能,只要仓库在不能,除非手动拷贝 shelf 目录默认是否含未跟踪文件不含,需-u/-a包含,只要在 changelist 里多份内容的管理方式栈结构,stash{n}下标访问列表结构,每条可自定义名称数据丢失风险手滑drop后有找回余地IDE 配置被清就彻底没了能否给别人用可导出 patch 或推引用部分版本支持导出 patch 后分享是否绑定分支不绑定,全仓库共享一个 stash 栈绑定项目,同一项目下共享把这张表读完,你会发现一个反直觉的事实:看起来更轻量的 Shelve,其实在数据安全性上更脆;看起来更重量级的 Stash,反而因为落在 Git 的对象库里,有了更多兜底手段。我后面讲找回技巧时会具体展开。2. 两个功能同时存在,分别解决了什么问题2.1 Stash 的不可替代性:跨工具、跨环境、可移植Stash 最硬的价值在于它是 Git 的一部分,而不是某个 IDE 的一部分。你今天用 IDEA,明天换成命令行、换成 VS Code、换成同事的机器,只要有那个仓库,git stash list一敲,东西就在那儿。这种不依赖编辑器的特性,在多人协作和排障场景里几乎是刚需。我遇到过好几次这种情况:线上出了个诡异问题,需要立刻切到发布分支去比对代码,但我手头这个功能分支改了一半没法提交。这时候git stash push -m wip: 订单状态机重构是最快的解法,切分支、处理问题、切回来、git stash pop,一气呵成。如果把这段改动换成 shelve,一旦中间需要同事远程接手看一眼,你就得先把它导成 patch 再发过去,多绕一道弯。还有一个实际场景:SHELL 环境下做自动化或者远程连服务器排障时,那边根本没有图形界面,shelve 这三个字压根不存在。所以但凡你有可能脱离本机 IDE 操作代码,stash 都是更稳的选择。2.2 Shelve 的主场:不想让本地改动沾上 Git 的边Shelve 的价值同样明确,而且很多人没意识到。第一类是根本不该出现在 Git 里的改动:临时加的一堆console.log、为了调某个接口硬编码的 token、本地把超时从 3 秒改成 30 秒的调试参数。这些东西连 stash 都不太合适——因为 stash 是仓库级的,手滑pop到别的分支上,你会瞬间把调试代码带到线上分支的工作区里。第二类是长期搁置。stash 列表是个栈,stash{0}只是最近一次,越往下标号越大,时间一长你根本记不清stash{7}是什么。shelve 可以给每条起名字,叫 实验性:换成 WebClient 调用,放三个月再回来看,名字还在。更关键的是,git stash列表长到十几个的时候,人的操作失误率会明显上升——git stash drop stash{5}这种命令,标号敲错一位后果就不同。第三类是只想撤掉一部分。假设我改了 5 个文件,其中 2 个是要保留继续写的新功能,另外 3 个是临时调试改动。用 shelve,我可以只勾选那 3 个文件,shelve 掉,剩下 2 个继续开发。用 stash 也可以git stash push path指定路径,但要一条一条列,文件多了很烦;而且在 IDEA 图形界面里,点勾选框明显比敲路径舒服。2.3 怎么选:我的默认判断规则总结成几条我自己的判断标准,你可以直接拿去用:切换分支处理紧急事务,预计一小时内回来:用Stash,顺手加-m备注,记得带-u如果新建了文件。改动涉及未跟踪的新文件,而且你嫌-u麻烦:用Shelve,它默认就把 changelist 里的新文件一起收走。调试代码、本地配置、临时打印:用Shelve,别让它有任何机会混进 Git。改动可能要放几天甚至几周:用Shelve,并且起一个能看懂的名字。需要同事帮忙看、或者你有可能换机器:用Stash,并且顺手git stash show -p wip.patch存一份补丁做双保险。只是想临时把工作区清干净跑一次构建:两个都行,但我一般直接 stash,因为快。注意:无论用哪个,养成存之前先看一眼存了什么的习惯。stash 用git stash show -p stash{0},shelve 直接在 Shelf 面板里双击对 diff。这个动作能挡掉八成恢复之后发现少了个文件的事故。3. 手把手实操:两种功能的完整操作路径3.1 Stash 的四种常用姿势先看命令行,这是最通用的方式。下面这几条命令覆盖了日常九成以上场景:# 最基础:把已跟踪文件的改动存起来 git stash push -m wip: 结算逻辑调整 # 连未跟踪的新文件一起存(推荐日常使用) git stash push -u -m wip: 新增对账模块 # 连被 .gitignore 忽略的文件也一起存(慎用,容易塞进一堆构建产物) git stash push -a -m wip: 包含构建产物 # 只存指定文件 git stash push -m wip: 只存前端 src/web/order.ts src/web/api.ts # 交互式挑选改动块,适合一个文件里混着两类改动 git stash push -p # 查看现有 stash 列表 git stash list # 输出形如:stash{0}: On feature/order: wip: 结算逻辑调整 # 看某一个 stash 的具体内容 git stash show -p stash{0} # 恢复但保留 stash 记录(推荐,确认无误后再手动删) git stash apply stash{0} # 恢复并删除记录(手滑就没得救,但更干净) git stash pop # 基于某个 stash 直接开新分支,处理stash 恢复后冲突太多的经典问题 git stash branch fix/from-stash stash{0} # 删掉某一条 git stash drop stash{0} # 清空所有 stash git stash clear这里有两个细节值得展开。第一,apply和pop的取舍。pop看起来更干净,但它在恢复后立刻删掉记录,一旦恢复过程中出了冲突、你手忙脚乱又执行了一次git checkout .,pop掉的那条就进入不可达对象状态,得靠git fsck去捞。apply恢复后记录还在,你可以先跑测试、确认没问题,再drop。多敲一条命令,换来的是可回退性,我认为非常值。第二,apply加不加--index差别很大。如果你 stash 之前已经git add了一部分文件,git stash apply --index会连暂存区状态一起还原,不加的话所有改动都会变成未暂存。IDE 里做提交时如果发现暂存区空了,别慌,大概率就是这个原因。图形界面这边,以 2023.x 版本的 IDEA 为例:打开 Git 工具窗口(Alt9),在仓库节点上右键,菜单里能找到Stash Changes...,弹出对话框填备注、勾选是否包含未跟踪文件,点Create Stash就行。恢复时在同一个窗口左侧的Stash标签页里选中某条,右键Apply Stash或Pop Stash。不同版本菜单位置略有差异,有的版本把入口放在提交窗口的齿轮菜单里,找不到时用CtrlShiftA搜 Stash 最快。3.2 Shelve 的完整操作流程Shelve 的操作链路比 stash 长一点,但每一步都有它的用意。第一步,先整理 changelist。IDEA 的 shelve 是围绕 changelist(本地变更列表)工作的,所以如果你改动的文件混在一起,先在提交窗口里把要 shelve 的文件拖到单独的 changelist,或者干脆全选。这一步的意义在于:shelve 之后,被收走的文件会从工作区消失,回到仓库版本;留在 changelist 里的继续保留。第二步,触发 Shelve。在提交窗口左侧栏找到Shelf标签页(如果没有显示,检查视图菜单里是否把它隐藏了),或者在 Git 工具窗口右键选择Shelve Changes...。弹出的对话框里可以填一段描述,并勾选具体要 shelve 的文件和改动块。第三步,确认 shelve 结果。点确定之后,工作区里被收走的文件会恢复成仓库版本,Shelf面板里出现一条新记录,双击就能看到完整 diff。这一步我强烈建议做一次核对——特别是有新增文件的时候,确认它确实进了 shelf,而不是被 silently 忽略掉了。第四步,在别的分支上继续干活。因为 shelf 不绑分支,你在哪条分支上都能看到它。第五步,Unshelve。在Shelf面板选中记录右键,选Unshelve...。这里有个小分叉:Unshelve Silently会直接把改动合并进当前 changelist;不带 Silently 的那个会弹对话框,让你指定目标 changelist、是否在恢复后删除这条 shelf。我一般选带对话框的那个,因为能看到它会往哪个 changelist 里放。第六步,处理冲突。如果当前分支上目标文件的对应位置已经改过,IDEA 会拉起合并工具让你逐块选择。这一步和 stash 恢复冲突的处理体验很像,区别在于 shelve 走的是 IDE 自己的三方合并器,界面更直观一些。3.3 恢复、冲突与误删后的找回技巧先说 stash 的找回。如果你手滑git stash drop或者git stash clear了,先别急着骂自己,绝大多数情况下还能救。执行:# 查看 stash 的 reflog,能看到最近的操作痕迹 git reflog show refs/stash # 列出所有不可达的 commit,配合 grep 找可疑对象 git fsck --unreachable --no-reflogs | grep commit拿到可疑的 commit hash 之后,用git show hash逐个看内容,确认是你要的那次 stash,然后git stash apply hash或者git cherry-pick回来。这个方法的成功率取决于你有没有跑过git gc——垃圾回收一旦执行,不可达对象就被物理删除了。所以发现误删要尽快处理,别拖到第二天。再说 shelve 的找回。情况就没这么乐观了。shelf 的文件在你的 IDE 配置目录里,如果那条记录还在 IDE 面板里,直接 unshelve 就行;如果是 IDE 配置目录被清空、或者换了机器,那就得去老机器的对应目录里把文件拷过来。以 2023.x 为例,路径大概在~/Library/Application Support/JetBrains/IntelliJIdea2023.x/shelf(macOS)或者%APPDATA%\JetBrains\IntelliJIdea2023.x\shelf(Windows)。拷过去之后,部分版本需要重启 IDE 才能识别。提示:如果你有跨机器同步改动文件的习惯,不要直接把整个 IDE 配置目录往同步盘里放——.idea里的缓存文件冲突起来非常麻烦。更稳妥的做法是把 shelf 目录单独挑出来同步,或者干脆改用 stash patch 兜底。还有一个很多人不知道的小技巧:部分版本支持把 shelf 导出成 patch 文件。在Shelf面板里右键某条记录,菜单里能看到导出相关的选项(不同版本可能叫Export Patch或Save as Patch)。导出的 patch 文件就是标准补丁格式,换台机器用git apply xxx.patch就能打回来,而且同事可以直接用。这个小功能把 shelve 的隔离性和 patch 的可移植性接在了一起,非常实用。4. 常见问题与排查技巧实录4.1 Your local changes will be overwritten by merge 到底怎么解这个报错大概是日常开发里出现频率最高的一条,完整版本通常是:Your local changes to the following files would be overwritten by merge: xxx. Please commit your stash or revert them.它出现的根本原因只有一个:Git 在 pull / merge / checkout 时,需要更新某些文件,而这些文件恰好有你未提交的本地改动。Git 不愿意擅自覆盖你的工作,于是直接罢工。排查顺序我一般是这样的:第一,先看清楚它列出来的文件清单。报错信息会明确列出文件名,别跳过这一段。如果只有一两个文件,处理成本很低。第二,判断这些改动值不值得留。如果只是 IDE 自动生成的无关改动(比如行尾符、格式化),直接git checkout -- file丢掉最省事。第三,如果值得留,用 stash 或者 shelve 收起来,再重试合并。命令是git stash push -u -m merge 前暂存,合并完再git stash pop。第四,如果改动量很大、合并后冲突不可避免,干脆先提交到当前分支,合并完成后统一处理冲突。这比 stash 更稳,因为 stash 在冲突时处理起来也很烦。第五,还有一个容易被忽略的情况:未跟踪文件占位。如果你本地有个新文件src/config/local.ts,而目标分支正好新增了同名文件,Git 也会拒绝合并。这时候的处理方式是先把本地文件改名或挪走,合并完再挪回来。4.2 stash 恢复后改动变少或冲突的典型原因很多人反馈过这个现象:stash 之后切回来pop,发现部分改动不见了。绝大多数不是数据丢了,而是下面几个原因。一是暂存区状态没还原。前面提过,不加--index的话,原本git add过的改动会全部变成未暂存状态,在 IDEA 的提交窗口里看起来就像少了一些,实际都在。对着工作区 diff 看一遍就清楚了。二是未跟踪文件根本没被存进去。如果你 stash 时没加-u,新建的文件不会进 stash,而git stash pop之后工作区是干净状态,那些新文件被 Git 留在原地没动,你可能会误以为丢了。实际上它们还在,只是没被 stash 管理过。三是冲突导致部分 hunk 被跳过。pop遇到冲突时会中断,已合并的部分留下了,冲突部分标了标记,而 stash 记录不会被删除(只有完全成功才删)。这时候正确的姿势是解决冲突、git add、然后手动git stash drop。千万别在冲突状态下再执行一次pop,会报错说已经存在。四是切分支时被 IDE 的自动操作干扰。IDEA 在切分支前会提示有未提交改动,是否 stash 或 shelve,如果你顺手点了,它可能已经帮你存了一次,而你自己又存了一次,于是列表里多一条。git stash list一看就明白。4.3 Shelve 相关的高频坑Shelve 的坑和 stash 完全不同,主要集中在环境绑定上。第一个坑:shelf条目在面板里看不见了。常见原因是换了 IDE 版本。IDEA 升级时配置目录名会跟着版本号变,旧版本的 shelf 目录不会自动迁移。解决办法是把旧目录里的文件拷到新版本的对应目录下。第二个坑:项目目录被重新 clone 到别的路径,之前基于旧路径的 shelf 找不到了。因为 shelf 在 IDE 配置里通常按项目路径区分,路径变了就相当于换了个项目。第三个坑:以为 shelve 能跨 IDE。如果你和同事一个用 IDEA、一个用 VS Code,shelve 完全帮不上忙。这种情况老老实实用 stash 加 patch。第四个坑:.idea目录被.gitignore忽略导致误判。有些同学看到项目里没有.idea/shelf就以为 shelf 丢了,其实是被忽略规则挡住了,真实文件在 IDE 配置目录里。用Help → Show Log in Explorer一类的方式定位配置目录更靠谱。4.4 问题速查表报错或现象大概率原因处理方式Your local changes would be overwritten目标分支要更新的文件有本地未提交改动先 stash / shelve,再合并;或先 commitstash pop 报冲突目标分支同名文件的对应位置已改解决冲突后git add,再手动 dropstash 恢复后暂存区空了恢复时没加--indexgit stash apply --index stash{0}stash 恢复后新文件不见了stash 时没带-u新文件其实还在工作区,检查未跟踪列表stash 列表太长记不清内容没加-m备注git stash show -p stash{n}逐个确认误 drop 了 stash手滑 之后没跑 gcgit fsck --unreachable找 commit 再 applyShelf 条目消失IDE 升级换了配置目录从旧版本配置目录拷贝 shelf 文件Unshelve 冲突太多目标分支改动较大先浏览 diff,必要时逐文件选,或改用 patch换电脑后 shelf 全没了shelf 只在本机 IDE 配置里改用 stash 或导出 patch 同步5. 我踩过的坑和几条实用心得5.1 别把 stash 当保险箱我最早用 stash 的时候有个坏习惯:改动一存就很久不管,列表里堆了二十几条,标号都记不住。有一次清理的时候git stash clear一把梭,结果把一条放了两周的实验性改动一起清了。那次之后我给自己定了个规矩:stash 里的东西超过一天,要么恢复继续做,要么转成 branch 或者 patch 存档,绝不让它长期躺在栈里。具体做法是git stash branch 新分支名 stash{n},这条命令会基于 stash 创建时的那个 commit 拉出一个新分支,然后把 stash 应用上去。如果真实历史已经跑远了、冲突太多,它会直接在原地报错,反而帮你省了时间。实验性代码从此有了分支名和提交记录,再也不会在栈里烂掉。5.2 团队里最好统一一下约定如果团队里几个人都用 IDEA,建议统一一条规则:凡是需要给同事看的临时改动,一律用 stash 并导出 patch;纯粹本地调试、绝不外传的,才用 shelve。这条规则看着简单,能省掉大量沟通成本。原因很实际:你拿 shelve 存的东西,同事无论如何都拿不到,你只能自己复述改了什么,沟通成本极高。而 stash 配git stash show -p stash{0} wip-日期.patch,一个文件发过去,对方git apply就能复现,连命令行输出都不用来回贴。另外,提交窗口里的 changelist 命名也值得规范一下。我习惯用功能名 状态的格式,比如order-refactor-wip,而不是默认的Default Changelist。这样 shelve 的时候不容易选错,恢复的时候也一眼能认出来。5.3 几个实战小技巧第一个,给 stash 起名要具体。-m wip等于没起名,-m wip: 结算金额精度改为 BigDecimal才是有用的。半年后你回头看列表,能省下大量show -p的时间。第二个,善用git stash show --stat stash{n}先看文件清单再决定要不要恢复。这一步比直接pop安全得多,尤其在列表很长的时候。第三个,shelve 之前先把不需要的改动撤掉。比如 IDE 自动改的行尾、临时注释掉的代码块,先git checkout --清掉,再 shelve,能显著减小后续 unshelve 的冲突面积。这是纯粹的经验之谈,文档里不会写。第四个,遇到必须立刻切分支的情况,最快的路径其实是先git stash push -u -m ...再切,不要走 IDE 弹窗里的确认流程——那个流程有时候会因为文件正在被索引而卡住一两秒,紧急时候很烦。第五个,定期检查git stash list和 Shelf 面板,把过期的清掉。这两处都是存进去就忘的重灾区,半年后你面对三十条记录时的痛苦,只有经历过才知道。最后一个我个人的体会:这两个功能没有谁替代谁的问题,真正的分界线只有两条——这份改动需不需要脱离本机、脱离这个 IDE?如果需要,就用 stash 并考虑导出 patch;如果确定只在本地、只在 IDE 里流转,那 shelve 更干净。至于哪个更高级哪个更安全这类争论,我现在的看法是:安全与否取决于你有没有留后手,而不是取决于你点了哪个按钮。stash 不留 patch、shelve 不同步文件,该丢的时候一样丢。真正救过我几次的,从来都不是某个菜单项,而是存之前多看一眼 diff、存之后顺手导出个补丁这两个习惯。
Git Stash 与 IDEA Shelve：底层机制、适用场景与恢复技巧
1. 从底层机制看:一个写进 .git,一个只留在 IDE 里先说结论:很多人以为 IDEA 的 Shelve 和 Git 的 Stash 只是同一个功能的两套皮,点哪个都一样。这个认知在实际项目里迟早会咬你一口。它们从存储位置、数据格式、生命周期到恢复方式,几乎没有一处是重合的。想搞清楚该用哪个,得先看它们各自往磁盘上写了什么。1.1 Git Stash 本质是一次隐藏的多方提交敲下git stash的那一刻,Git 干的并不是把文件挪到某个角落这么简单。它实际上做了三件事:先把当前工作区的改动打包成一个 commit 对象,再把暂存区(index)的状态打包成另一个 commit 对象,然后把工作区和暂存区都重置回 HEAD 的干净状态。这个打包出来的 commit 不挂在任何分支上,而是由.git/refs/stash这个引用指向,同时在.git/logs/refs/stash里留下一条 reflog 记录。正因为它是货真价实的 commit 对象,git show stash{0}、git diff stash{0}这类命令全都能用,甚至可以把它打成补丁文件发给同事。stash{0}这个写法本身就是 reflog 语法——{0}是最近一次,{1}往前推一次。这同时也解释了另一个常见疑问:为什么git log里看不到你 stash 的东西?因为它压根不在当前分支的提交链上,只是被一个特殊引用拽着,不让垃圾回收把它清掉。还有一点特别容易被忽略:stash 默认不收未跟踪文件(untracked)和被忽略文件(ignored),要额外加-u/--include-untracked或者-a/--all。为什么默认不收?因为未跟踪文件里往往混着构建产物、临时日志、本地私有配置,一股脑塞进去只会让下次恢复变成一个大型灾难现场。这是设计上的取舍,不是 bug。1.2 IDEA Shelve 只干一件事:把 diff 搬进 IDE 的目录IDEA 的 Shelve 走的是完全另一条路。它不碰.git目录里的任何东西——不创建 commit、不动 HEAD、不写 reflog、不留引用。它做的事情是把当前 changelist 里选中文件的 diff(补丁)序列化成一个文件,存到 IDE 配置目录下的shelf文件夹里,然后把工作区中这些改动撤掉,让你的代码回到看起来干净的状态。这个路径大致是这样:Windows 上在%APPDATA%\JetBrains\IntelliJIdea版本号\shelf,macOS 上在~/Library/Application Support/JetBrains/IntelliJIdea版本号/shelf,Linux 上在~/.config/JetBrains/IntelliJIdea版本号/shelf。更早的版本曾经把它放在项目的.idea/shelf目录里,所以你在老项目里翻到这个文件夹也别意外。以 2023.x 版本为例,目录名里的版本号会跟着 IDE 升级变,不同版本的具体位置也略有出入,但大方向就是跟着 IDE 配置走,不跟着仓库走。这意味着什么?shelve 出来的东西只有 IntelliJ 系 IDE 认,命令行 Git 对它一无所知。你换一台电脑、重装一次 IDE、手滑清掉配置目录,shelf 就没了。反过来看,它也绝不会污染任何人的 Git 历史:不会出现在git log里,不会跟着 push 跑到远端,同事在仓库里永远看不到你本地存过什么。这种彻底的私有性在某些场景下是优点,在另一些场景下是致命的缺点。另一个关键差异是粒度。shelve 以 changelist 为单位,你可以在Shelve Changes对话框里只勾选某几个文件,甚至只 shelve 单个文件里的某几个改动块(hunk)。stash 当然也能做到——git stash push -p支持交互式挑选 hunk——但纯命令行做这件事的手感,用过的同学心里都有数。1.3 一张表把两者的关键属性摆在一起对比维度Git StashIDEA Shelve底层形态真实的 commit 对象 reflogIDE 私有的补丁文件存储位置仓库内.git目录IDE 配置目录下的 shelf 文件夹是否进 Git 历史不进分支历史,但进 reflog完全不进 Git命令行能否识别能,git stash list全都能操作不能,只有 IDE 认换电脑能否恢复能,只要仓库在不能,除非手动拷贝 shelf 目录默认是否含未跟踪文件不含,需-u/-a包含,只要在 changelist 里多份内容的管理方式栈结构,stash{n}下标访问列表结构,每条可自定义名称数据丢失风险手滑drop后有找回余地IDE 配置被清就彻底没了能否给别人用可导出 patch 或推引用部分版本支持导出 patch 后分享是否绑定分支不绑定,全仓库共享一个 stash 栈绑定项目,同一项目下共享把这张表读完,你会发现一个反直觉的事实:看起来更轻量的 Shelve,其实在数据安全性上更脆;看起来更重量级的 Stash,反而因为落在 Git 的对象库里,有了更多兜底手段。我后面讲找回技巧时会具体展开。2. 两个功能同时存在,分别解决了什么问题2.1 Stash 的不可替代性:跨工具、跨环境、可移植Stash 最硬的价值在于它是 Git 的一部分,而不是某个 IDE 的一部分。你今天用 IDEA,明天换成命令行、换成 VS Code、换成同事的机器,只要有那个仓库,git stash list一敲,东西就在那儿。这种不依赖编辑器的特性,在多人协作和排障场景里几乎是刚需。我遇到过好几次这种情况:线上出了个诡异问题,需要立刻切到发布分支去比对代码,但我手头这个功能分支改了一半没法提交。这时候git stash push -m wip: 订单状态机重构是最快的解法,切分支、处理问题、切回来、git stash pop,一气呵成。如果把这段改动换成 shelve,一旦中间需要同事远程接手看一眼,你就得先把它导成 patch 再发过去,多绕一道弯。还有一个实际场景:SHELL 环境下做自动化或者远程连服务器排障时,那边根本没有图形界面,shelve 这三个字压根不存在。所以但凡你有可能脱离本机 IDE 操作代码,stash 都是更稳的选择。2.2 Shelve 的主场:不想让本地改动沾上 Git 的边Shelve 的价值同样明确,而且很多人没意识到。第一类是根本不该出现在 Git 里的改动:临时加的一堆console.log、为了调某个接口硬编码的 token、本地把超时从 3 秒改成 30 秒的调试参数。这些东西连 stash 都不太合适——因为 stash 是仓库级的,手滑pop到别的分支上,你会瞬间把调试代码带到线上分支的工作区里。第二类是长期搁置。stash 列表是个栈,stash{0}只是最近一次,越往下标号越大,时间一长你根本记不清stash{7}是什么。shelve 可以给每条起名字,叫 实验性:换成 WebClient 调用,放三个月再回来看,名字还在。更关键的是,git stash列表长到十几个的时候,人的操作失误率会明显上升——git stash drop stash{5}这种命令,标号敲错一位后果就不同。第三类是只想撤掉一部分。假设我改了 5 个文件,其中 2 个是要保留继续写的新功能,另外 3 个是临时调试改动。用 shelve,我可以只勾选那 3 个文件,shelve 掉,剩下 2 个继续开发。用 stash 也可以git stash push path指定路径,但要一条一条列,文件多了很烦;而且在 IDEA 图形界面里,点勾选框明显比敲路径舒服。2.3 怎么选:我的默认判断规则总结成几条我自己的判断标准,你可以直接拿去用:切换分支处理紧急事务,预计一小时内回来:用Stash,顺手加-m备注,记得带-u如果新建了文件。改动涉及未跟踪的新文件,而且你嫌-u麻烦:用Shelve,它默认就把 changelist 里的新文件一起收走。调试代码、本地配置、临时打印:用Shelve,别让它有任何机会混进 Git。改动可能要放几天甚至几周:用Shelve,并且起一个能看懂的名字。需要同事帮忙看、或者你有可能换机器:用Stash,并且顺手git stash show -p wip.patch存一份补丁做双保险。只是想临时把工作区清干净跑一次构建:两个都行,但我一般直接 stash,因为快。注意:无论用哪个,养成存之前先看一眼存了什么的习惯。stash 用git stash show -p stash{0},shelve 直接在 Shelf 面板里双击对 diff。这个动作能挡掉八成恢复之后发现少了个文件的事故。3. 手把手实操:两种功能的完整操作路径3.1 Stash 的四种常用姿势先看命令行,这是最通用的方式。下面这几条命令覆盖了日常九成以上场景:# 最基础:把已跟踪文件的改动存起来 git stash push -m wip: 结算逻辑调整 # 连未跟踪的新文件一起存(推荐日常使用) git stash push -u -m wip: 新增对账模块 # 连被 .gitignore 忽略的文件也一起存(慎用,容易塞进一堆构建产物) git stash push -a -m wip: 包含构建产物 # 只存指定文件 git stash push -m wip: 只存前端 src/web/order.ts src/web/api.ts # 交互式挑选改动块,适合一个文件里混着两类改动 git stash push -p # 查看现有 stash 列表 git stash list # 输出形如:stash{0}: On feature/order: wip: 结算逻辑调整 # 看某一个 stash 的具体内容 git stash show -p stash{0} # 恢复但保留 stash 记录(推荐,确认无误后再手动删) git stash apply stash{0} # 恢复并删除记录(手滑就没得救,但更干净) git stash pop # 基于某个 stash 直接开新分支,处理stash 恢复后冲突太多的经典问题 git stash branch fix/from-stash stash{0} # 删掉某一条 git stash drop stash{0} # 清空所有 stash git stash clear这里有两个细节值得展开。第一,apply和pop的取舍。pop看起来更干净,但它在恢复后立刻删掉记录,一旦恢复过程中出了冲突、你手忙脚乱又执行了一次git checkout .,pop掉的那条就进入不可达对象状态,得靠git fsck去捞。apply恢复后记录还在,你可以先跑测试、确认没问题,再drop。多敲一条命令,换来的是可回退性,我认为非常值。第二,apply加不加--index差别很大。如果你 stash 之前已经git add了一部分文件,git stash apply --index会连暂存区状态一起还原,不加的话所有改动都会变成未暂存。IDE 里做提交时如果发现暂存区空了,别慌,大概率就是这个原因。图形界面这边,以 2023.x 版本的 IDEA 为例:打开 Git 工具窗口(Alt9),在仓库节点上右键,菜单里能找到Stash Changes...,弹出对话框填备注、勾选是否包含未跟踪文件,点Create Stash就行。恢复时在同一个窗口左侧的Stash标签页里选中某条,右键Apply Stash或Pop Stash。不同版本菜单位置略有差异,有的版本把入口放在提交窗口的齿轮菜单里,找不到时用CtrlShiftA搜 Stash 最快。3.2 Shelve 的完整操作流程Shelve 的操作链路比 stash 长一点,但每一步都有它的用意。第一步,先整理 changelist。IDEA 的 shelve 是围绕 changelist(本地变更列表)工作的,所以如果你改动的文件混在一起,先在提交窗口里把要 shelve 的文件拖到单独的 changelist,或者干脆全选。这一步的意义在于:shelve 之后,被收走的文件会从工作区消失,回到仓库版本;留在 changelist 里的继续保留。第二步,触发 Shelve。在提交窗口左侧栏找到Shelf标签页(如果没有显示,检查视图菜单里是否把它隐藏了),或者在 Git 工具窗口右键选择Shelve Changes...。弹出的对话框里可以填一段描述,并勾选具体要 shelve 的文件和改动块。第三步,确认 shelve 结果。点确定之后,工作区里被收走的文件会恢复成仓库版本,Shelf面板里出现一条新记录,双击就能看到完整 diff。这一步我强烈建议做一次核对——特别是有新增文件的时候,确认它确实进了 shelf,而不是被 silently 忽略掉了。第四步,在别的分支上继续干活。因为 shelf 不绑分支,你在哪条分支上都能看到它。第五步,Unshelve。在Shelf面板选中记录右键,选Unshelve...。这里有个小分叉:Unshelve Silently会直接把改动合并进当前 changelist;不带 Silently 的那个会弹对话框,让你指定目标 changelist、是否在恢复后删除这条 shelf。我一般选带对话框的那个,因为能看到它会往哪个 changelist 里放。第六步,处理冲突。如果当前分支上目标文件的对应位置已经改过,IDEA 会拉起合并工具让你逐块选择。这一步和 stash 恢复冲突的处理体验很像,区别在于 shelve 走的是 IDE 自己的三方合并器,界面更直观一些。3.3 恢复、冲突与误删后的找回技巧先说 stash 的找回。如果你手滑git stash drop或者git stash clear了,先别急着骂自己,绝大多数情况下还能救。执行:# 查看 stash 的 reflog,能看到最近的操作痕迹 git reflog show refs/stash # 列出所有不可达的 commit,配合 grep 找可疑对象 git fsck --unreachable --no-reflogs | grep commit拿到可疑的 commit hash 之后,用git show hash逐个看内容,确认是你要的那次 stash,然后git stash apply hash或者git cherry-pick回来。这个方法的成功率取决于你有没有跑过git gc——垃圾回收一旦执行,不可达对象就被物理删除了。所以发现误删要尽快处理,别拖到第二天。再说 shelve 的找回。情况就没这么乐观了。shelf 的文件在你的 IDE 配置目录里,如果那条记录还在 IDE 面板里,直接 unshelve 就行;如果是 IDE 配置目录被清空、或者换了机器,那就得去老机器的对应目录里把文件拷过来。以 2023.x 为例,路径大概在~/Library/Application Support/JetBrains/IntelliJIdea2023.x/shelf(macOS)或者%APPDATA%\JetBrains\IntelliJIdea2023.x\shelf(Windows)。拷过去之后,部分版本需要重启 IDE 才能识别。提示:如果你有跨机器同步改动文件的习惯,不要直接把整个 IDE 配置目录往同步盘里放——.idea里的缓存文件冲突起来非常麻烦。更稳妥的做法是把 shelf 目录单独挑出来同步,或者干脆改用 stash patch 兜底。还有一个很多人不知道的小技巧:部分版本支持把 shelf 导出成 patch 文件。在Shelf面板里右键某条记录,菜单里能看到导出相关的选项(不同版本可能叫Export Patch或Save as Patch)。导出的 patch 文件就是标准补丁格式,换台机器用git apply xxx.patch就能打回来,而且同事可以直接用。这个小功能把 shelve 的隔离性和 patch 的可移植性接在了一起,非常实用。4. 常见问题与排查技巧实录4.1 Your local changes will be overwritten by merge 到底怎么解这个报错大概是日常开发里出现频率最高的一条,完整版本通常是:Your local changes to the following files would be overwritten by merge: xxx. Please commit your stash or revert them.它出现的根本原因只有一个:Git 在 pull / merge / checkout 时,需要更新某些文件,而这些文件恰好有你未提交的本地改动。Git 不愿意擅自覆盖你的工作,于是直接罢工。排查顺序我一般是这样的:第一,先看清楚它列出来的文件清单。报错信息会明确列出文件名,别跳过这一段。如果只有一两个文件,处理成本很低。第二,判断这些改动值不值得留。如果只是 IDE 自动生成的无关改动(比如行尾符、格式化),直接git checkout -- file丢掉最省事。第三,如果值得留,用 stash 或者 shelve 收起来,再重试合并。命令是git stash push -u -m merge 前暂存,合并完再git stash pop。第四,如果改动量很大、合并后冲突不可避免,干脆先提交到当前分支,合并完成后统一处理冲突。这比 stash 更稳,因为 stash 在冲突时处理起来也很烦。第五,还有一个容易被忽略的情况:未跟踪文件占位。如果你本地有个新文件src/config/local.ts,而目标分支正好新增了同名文件,Git 也会拒绝合并。这时候的处理方式是先把本地文件改名或挪走,合并完再挪回来。4.2 stash 恢复后改动变少或冲突的典型原因很多人反馈过这个现象:stash 之后切回来pop,发现部分改动不见了。绝大多数不是数据丢了,而是下面几个原因。一是暂存区状态没还原。前面提过,不加--index的话,原本git add过的改动会全部变成未暂存状态,在 IDEA 的提交窗口里看起来就像少了一些,实际都在。对着工作区 diff 看一遍就清楚了。二是未跟踪文件根本没被存进去。如果你 stash 时没加-u,新建的文件不会进 stash,而git stash pop之后工作区是干净状态,那些新文件被 Git 留在原地没动,你可能会误以为丢了。实际上它们还在,只是没被 stash 管理过。三是冲突导致部分 hunk 被跳过。pop遇到冲突时会中断,已合并的部分留下了,冲突部分标了标记,而 stash 记录不会被删除(只有完全成功才删)。这时候正确的姿势是解决冲突、git add、然后手动git stash drop。千万别在冲突状态下再执行一次pop,会报错说已经存在。四是切分支时被 IDE 的自动操作干扰。IDEA 在切分支前会提示有未提交改动,是否 stash 或 shelve,如果你顺手点了,它可能已经帮你存了一次,而你自己又存了一次,于是列表里多一条。git stash list一看就明白。4.3 Shelve 相关的高频坑Shelve 的坑和 stash 完全不同,主要集中在环境绑定上。第一个坑:shelf条目在面板里看不见了。常见原因是换了 IDE 版本。IDEA 升级时配置目录名会跟着版本号变,旧版本的 shelf 目录不会自动迁移。解决办法是把旧目录里的文件拷到新版本的对应目录下。第二个坑:项目目录被重新 clone 到别的路径,之前基于旧路径的 shelf 找不到了。因为 shelf 在 IDE 配置里通常按项目路径区分,路径变了就相当于换了个项目。第三个坑:以为 shelve 能跨 IDE。如果你和同事一个用 IDEA、一个用 VS Code,shelve 完全帮不上忙。这种情况老老实实用 stash 加 patch。第四个坑:.idea目录被.gitignore忽略导致误判。有些同学看到项目里没有.idea/shelf就以为 shelf 丢了,其实是被忽略规则挡住了,真实文件在 IDE 配置目录里。用Help → Show Log in Explorer一类的方式定位配置目录更靠谱。4.4 问题速查表报错或现象大概率原因处理方式Your local changes would be overwritten目标分支要更新的文件有本地未提交改动先 stash / shelve,再合并;或先 commitstash pop 报冲突目标分支同名文件的对应位置已改解决冲突后git add,再手动 dropstash 恢复后暂存区空了恢复时没加--indexgit stash apply --index stash{0}stash 恢复后新文件不见了stash 时没带-u新文件其实还在工作区,检查未跟踪列表stash 列表太长记不清内容没加-m备注git stash show -p stash{n}逐个确认误 drop 了 stash手滑 之后没跑 gcgit fsck --unreachable找 commit 再 applyShelf 条目消失IDE 升级换了配置目录从旧版本配置目录拷贝 shelf 文件Unshelve 冲突太多目标分支改动较大先浏览 diff,必要时逐文件选,或改用 patch换电脑后 shelf 全没了shelf 只在本机 IDE 配置里改用 stash 或导出 patch 同步5. 我踩过的坑和几条实用心得5.1 别把 stash 当保险箱我最早用 stash 的时候有个坏习惯:改动一存就很久不管,列表里堆了二十几条,标号都记不住。有一次清理的时候git stash clear一把梭,结果把一条放了两周的实验性改动一起清了。那次之后我给自己定了个规矩:stash 里的东西超过一天,要么恢复继续做,要么转成 branch 或者 patch 存档,绝不让它长期躺在栈里。具体做法是git stash branch 新分支名 stash{n},这条命令会基于 stash 创建时的那个 commit 拉出一个新分支,然后把 stash 应用上去。如果真实历史已经跑远了、冲突太多,它会直接在原地报错,反而帮你省了时间。实验性代码从此有了分支名和提交记录,再也不会在栈里烂掉。5.2 团队里最好统一一下约定如果团队里几个人都用 IDEA,建议统一一条规则:凡是需要给同事看的临时改动,一律用 stash 并导出 patch;纯粹本地调试、绝不外传的,才用 shelve。这条规则看着简单,能省掉大量沟通成本。原因很实际:你拿 shelve 存的东西,同事无论如何都拿不到,你只能自己复述改了什么,沟通成本极高。而 stash 配git stash show -p stash{0} wip-日期.patch,一个文件发过去,对方git apply就能复现,连命令行输出都不用来回贴。另外,提交窗口里的 changelist 命名也值得规范一下。我习惯用功能名 状态的格式,比如order-refactor-wip,而不是默认的Default Changelist。这样 shelve 的时候不容易选错,恢复的时候也一眼能认出来。5.3 几个实战小技巧第一个,给 stash 起名要具体。-m wip等于没起名,-m wip: 结算金额精度改为 BigDecimal才是有用的。半年后你回头看列表,能省下大量show -p的时间。第二个,善用git stash show --stat stash{n}先看文件清单再决定要不要恢复。这一步比直接pop安全得多,尤其在列表很长的时候。第三个,shelve 之前先把不需要的改动撤掉。比如 IDE 自动改的行尾、临时注释掉的代码块,先git checkout --清掉,再 shelve,能显著减小后续 unshelve 的冲突面积。这是纯粹的经验之谈,文档里不会写。第四个,遇到必须立刻切分支的情况,最快的路径其实是先git stash push -u -m ...再切,不要走 IDE 弹窗里的确认流程——那个流程有时候会因为文件正在被索引而卡住一两秒,紧急时候很烦。第五个,定期检查git stash list和 Shelf 面板,把过期的清掉。这两处都是存进去就忘的重灾区,半年后你面对三十条记录时的痛苦,只有经历过才知道。最后一个我个人的体会:这两个功能没有谁替代谁的问题,真正的分界线只有两条——这份改动需不需要脱离本机、脱离这个 IDE?如果需要,就用 stash 并考虑导出 patch;如果确定只在本地、只在 IDE 里流转,那 shelve 更干净。至于哪个更高级哪个更安全这类争论,我现在的看法是:安全与否取决于你有没有留后手,而不是取决于你点了哪个按钮。stash 不留 patch、shelve 不同步文件,该丢的时候一样丢。真正救过我几次的,从来都不是某个菜单项,而是存之前多看一眼 diff、存之后顺手导出个补丁这两个习惯。 
