git stash用于临时保存未提交的修改以解决分支切换报错问题，支持stash -u暂存未跟踪文件、stash -a暂存所有文件，恢复时可用stash pop或stash apply，冲突需手动解决。
git stash 保存当前未提交修改
Git 不允许直接切换分支，如果工作区或暂存区有未提交的变更，git checkout 或 git switch 会报错：error: Your local changes to the following files would be overwritten by checkout。最稳妥的做法是先用 git stash 把改动暂存起来。
执行 git stash 后，Git 会把当前工作区和暂存区的变更打包压入栈顶，工作区恢复到 HEAD 状态，此时就能自由切换分支了。默认只 stash 已跟踪文件的修改；如果还有新增但未 git add 的文件，需加 -u 参数：git stash -u；若连未跟踪的配置文件、日志等也要一并暂存，用 -a（即 git stash -a）。
-
git stash不会触碰已忽略文件（由.gitignore定义） - 多次
git stash会形成栈，后续可用git stash list查看 - stash 是本地操作，不会推送到远程仓库
切换分支后恢复 stash
切到目标分支后，用 git stash pop 恢复最近一次 stash 并从栈中移除；若只想应用不删除，用 git stash apply。注意：恢复时可能产生冲突，尤其是修改过同一文件的相同区域——Git 会像合并一样标记冲突，需手动解决后 git add + git commit。
如果目标分支没有 stash 中涉及的文件（比如该文件在目标分支里被删了），git stash pop 会失败并提示 fatal: ambiguous argument 'stash@{0}': unknown revision，此时改用 git stash apply stash@{0} 可能更安全，它不会自动清理栈，便于回退。
- 恢复前建议先
git status确认工作区干净，避免叠加混乱 - 不同分支的文件结构差异越大，冲突概率越高，尤其涉及重命名或删除操作
-
git stash pop失败后，stash 仍保留在栈中，可继续尝试apply或drop
不 stash 直接跨分支暂存（git restore + git switch）
Git 2.23+ 提供了更细粒度的暂存方式：用 git restore 把部分修改“撤回”到暂存区或工作区，再配合 git switch 切换。但这不是真正“移动”修改，而是临时丢弃或保留部分变更。
例如，只想保留某个配置文件的修改去新分支，其余先不管：先 git add config.json，再 git restore --staged . 撤回其他暂存，接着 git restore . 清空其余工作区变更，最后 git switch feature-x 就能带着 config.json 的修改过去。这种方式适合明确知道哪些文件要带过去、哪些可丢弃的场景。
-
git restore .会丢弃所有未暂存修改，不可逆，请确认 -
git restore --staged只影响暂存区，不影响工作区 - 这种操作不记录历史，也不生成 stash 记录，适合快速试探性切换
常见误操作与风险点
有人试图用 git checkout -b new-branch 强行创建分支并携带修改，结果发现新分支里确实有改动，但原分支的 HEAD 并未更新——这其实是 Git 的“软切换”，本质是新建分支指向当前提交，然后把修改留在工作区。问题在于：这些修改不属于任何提交，一旦在新分支上做了提交，原分支就彻底丢失这部分变更上下文。
- 不要依赖
git checkout -b来“移动”修改，它不解决跨分支一致性问题 -
git stash push -m "msg"加描述比默认命名更易识别，尤其多人协作时 - 长期 stash 不恢复容易遗忘，
git stash drop或git stash clear要谨慎执行
真正麻烦的不是怎么存或取，而是 stash 内容和目标分支的代码演进是否兼容——比如你在 dev 分支改了函数签名，而 target 分支里这个函数已被重构，这时候 pop 出来的冲突就得逐行比对逻辑，没法靠工具自动解决。
