git stash 命令用于临时保存工作区和暂存区的全部未提交变更，不创建新提交、不影响 HEAD，仅将修改压入栈中，便于安全切换分支；恢复时可用 git stash apply 或 pop，支持指定索引精准应用，并需手动处理冲突。
git stash 保存当前修改再切分支
直接用 git stash 就能暂存工作区和暂存区的全部未提交变更，包括已 git add 但没 git commit 的内容，也包括未 add 的脏文件。它不会影响 HEAD 指向，也不创建新提交，只是把变更压进一个栈。
常见错误是以为 git checkout 或 git switch 能自动处理冲突修改——其实只要目标分支有同名文件且内容不同，Git 就会拒绝切换，并提示 “error: Your local changes to the following files would be overwritten…”。
-
git stash后再git switch feature/login就能无阻碍切换 - 如果只想暂存已
add的部分（保留未add的改动），用git stash --keep-index - 想同时记录 stash 的用途，加
-m "fix login timeout"，后续用git stash list可读性更强
git stash pop 恢复时遇到冲突怎么办
执行 git stash pop 本质是先 git stash apply 再 git stash drop。如果恢复时发生冲突，Git 不会自动中止，而是把冲突标记写进文件（如 <<<< HEAD），同时保留 stash 记录——也就是说，pop 失败后，stash 还在栈里，可以手动解决完再 git stash drop。
容易踩的坑是：误以为 pop 失败就丢了改动，其实 stash 没被删；更危险的是不检查冲突标记，直接 git add . && git commit，把冲突块一起提交了。
- 先运行
git status看哪些文件 CONFLICTED - 编辑冲突文件，删掉
<<<</====/>>>>标记，保留正确逻辑 - 确认无误后
git add <file>，再git stash drop（别用pop重试）
多个 stash 如何精准应用某一条
git stash 是栈结构，git stash pop 默认操作栈顶（stash@{0}）。但实际开发中常有多个临时改动堆叠，比如：先 stash A → 切分支修 bug → 回来又 stash B → 想只恢复 A。
这时候不能只靠 pop，得用带索引的 apply：
- 查列表：
git stash list输出类似stash@{0}: On main: fix api timeout - 应用第 2 条：
git stash apply stash@{1}（注意索引从 0 开始） - 应用后不删除该 stash，要清理才手动
git stash drop stash@{1} - 如果想“取出并删”，没有内置命令，只能
apply+drop两步走
git switch --discard-changes 强制丢弃修改切分支（慎用）
当确定不需要当前所有修改，想快速干净切换时，git switch -c new-branch --discard-changes 或 git switch main --discard-changes 可跳过 stash 步骤。但它会**不可逆删除工作区和暂存区所有未提交变更**，连刚写的几行调试代码也没了。
这个选项适合本地实验性代码、生成器脚本输出等明确可丢的内容。线上协作中，只要不确定是否还要用，就别碰 --discard-changes。
- 它不适用于已
git add的文件——add 过的变更仍会被丢弃，且无提示 - 相比
git checkout -f，git switch更安全，但--discard-changes本质上就是强制覆盖 - 真正保险的做法仍是
git stash && git switch，哪怕多敲两个词
git stash。但要注意：stash 不跨仓库同步，也不进 reflog，一旦 drop 就真没了。 
