北京
一个共享工作区里躺着20个文件的暂存改动，56处新增、1305处删除。第一反应多半是：谁动了我的代码？但把文件和提交历史摆在一起看，这些改动反映的是大约三周前的状态，不是新编辑。
这就是整件事最反常识的地方：diff 看起来像一场大手术，实际上是一具没被清理的旧尸体。处理方式也不复杂——先把旧状态存到分支上，再用reset --hard和pull --ff-only把工作区更新到最新。
为什么没把 diff 当成新改动
第一步是拿暂存内容和磁盘上的文件做对比。索引是改动进入下一次提交前的存放处。对比结果是：工作区和索引之间没有差异，也没有未跟踪文件。
也就是说，这不是"旧改动只残留在索引里"的情况。磁盘上的文件本身就是旧状态。diff 里显示为删除的那些文件，在磁盘上同样不存在。
于是可以停止把暂存内容当作新工作了。三个缺失的文件在事发前两天就已经被并入。它们分别覆盖测试框架、用量测量和上下文提示。
主分支的 HEAD（指向当前提交的名字）自事发当天的合并提交起，已经卡了大约三周。单看 diff 的大小解释不了发生了什么。把提交时间线和文件是否存在放在一起看，才能判断这是更早状态的残留，而不是最近的编辑。
只做 stash 为什么救不回工作区
如果 stash 完就停手，主工作区里仍然是那棵旧树。从这个状态构建，用的还是旧版本，下一次回滚照样发生。
stash 的作用是把残留物保存下来、不至于丢失。它和"把工作区恢复到当前状态"是两件事。只做其中一步，共享工作区对下一个任务来说仍然不可用。
所以这里把"保存旧状态"和"把主工作区更新到最新版本"当成同一个恢复流程来处理。
旧改动怎么存，主分支怎么更新
先把剩余的工作作为一个提交保存到有名字的分支上，这个分支充当一条独立工作线的标记。保留备份分支意味着内容之后还能复查。这个分支没有被删除。
接着运行reset --hard，让工作区与 HEAD 对齐。然后用pull --ff-only更新。结果是一次196个提交的快进，没有产生合并提交。
stash 同样被保留下来，没有删除。这样旧内容留住了，主工作区也往前走了。
为什么第四次 stash pop 才失败
事后了解到的情况是：同样的步骤当天成功过三次，第四次才第一次失败。失败时显示的是The stash entry is kept。至于为什么偏偏第四次失败，原因无法确定，也就不能声称知道原因。
这次能确认的是：共享工作区里仍然留着大约三周前的状态，磁盘上的文件和索引一样陈旧。同时也学到一点——光靠 stash 保存改动，恢复并不算完成。
通过保存旧状态来"恢复"，和通过把主工作区带到最新来"更新"，可以当作两个独立步骤。但在共享工作区里，恢复意味着两步都做完。stash 之后更新了主树，才没有带着旧树进入下一次构建。
- git diff --shortstat看 diff 规模。
- 检查工作区与索引的差异，并留意未跟踪文件。
- 对比文件是否存在、改动何时并入、以及 HEAD 的位置。
- 把旧改动保存到分支，再运行 reset --hard 和 pull --ff-only。
- 分支和 stash 都留着，方便之后复查。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
