git stash 是最常用且安全的保留方式，它将工作区和暂存区修改压栈保存并恢复干净工作目录；默认不保存未跟踪文件，需加 -u 参数；恢复可用 pop 或 apply，冲突需手动解决。
不能直接切，Git 会拒绝操作 —— 这不是 bug，是保护机制。你有三种可靠路径：stash、临时 commit、临时分支，选哪个取决于“修改是否已完成”和“后续是否要继续开发”。
git stash 是最常用且安全的保留方式
它把当前工作区和暂存区的全部修改“压栈”保存，同时让工作目录退回到 HEAD 状态，干净得像刚 git checkout 过一样。
- 默认不保存未跟踪（untracked）文件；需加
-u参数才一并暂存：git stash push -u -m "wip: api auth" - 恢复时用
git stash pop（应用并删除该条 stash），或git stash apply stash@{0}（仅应用，保留 stash 记录） - 冲突时 Git 不会中止，而是留下
标记，必须手动解决后再 <code>git add+git stash drop -
git stash list可查看所有 stash，每条带时间戳和可读描述（推荐始终加-m）
临时 commit 更适合“已完成但未提交”的场景
比如你改完了某个功能点，只是还没来得及写 commit message 或走 review 流程。这时 commit 比 stash 更自然、更可追溯。
- 执行
git add . && git commit -m "WIP: user profile form"，再git checkout切走 - 回来后若想撤销这次提交但保留代码，用
git reset --mixed HEAD^（保留工作区修改，清空暂存区） - 注意：
git reset --hard HEAD^会彻底丢弃代码，不可逆 - 这种 commit 不必 push，本地存在即可；后续 rebase 或 amend 都方便
临时分支适合“修改本身就有长期价值”的情况
当你清楚这些改动不是“临时跳转一下”，而是未来要基于它迭代、测试甚至合入主线时，分支比 stash 更合适。
- 创建并切换：
git checkout -b wip-ux-refactor - 提交当前所有修改：
git add . && git commit -m "feat: initial ux refactor" - 之后可自由切到
main或develop处理紧急任务，这个分支完整保留上下文 - 后续用
git rebase develop或git merge wip-ux-refactor整合，而不是靠 stash 搬运
容易被忽略的关键细节
git stash 不处理 untracked 文件，git checkout -f 也不动它们 —— 它们会原样留在工作区。这意味着你执行 git status --porcelain 后看到的 ?? file.txt，在 stash/pop 全流程中始终存在，可能造成误判。真要统一管理，得额外判断输出并决定是否 git add -N 或 git clean。这不是边缘情况，而是日常高频踩坑点。
