stash 不是用来“同步分支”的，而是用来在切换分支前临时藏起未完成修改的；它只保存当前工作区和暂存区的改动，是本地快照，非分支同步工具。
直接说结论：stash 不是用来“同步分支”的，而是用来在切换分支前临时藏起未完成修改的。如果你指望它解决远程分支拉取冲突、合并差异或保持多分支代码一致，那从一开始就想错了。
git stash 保存的是什么？
它只保存你当前工作区（Working Directory）和暂存区（Index）里的所有改动，不涉及任何远程分支状态、提交历史或远程跟踪信息。换句话说：git stash 做的只是“本地快照”，不是“分支同步工具”。
常见误解场景：
- 你在
feature/login上改了src/api/auth.js，还没git add—— 这部分会被 stash - 你已经
git add src/api/auth.js但没commit—— 这部分也会被 stash - 你刚
git pull origin main失败，提示 “Your local changes would be overwritten” —— 这时 stash 是解法之一，但它不帮你拉新代码，只是先腾出干净工作区
切换分支前必须 stash 吗？
不一定。Git 允许你带着修改切分支，前提是目标分支的对应文件没变过。但现实里几乎总会撞上冲突风险，所以安全起见，建议默认 stash。
GitHub操作助手
下载
用大白话操作当前项目的 Git/GitHub——配置 GitHub（装 gh CLI + 登录 + 建仓库）、备份、拉取下载、查询历史、回滚代码、管理分支。当用户用日常语言表达 git 意图时触发（例如"git备份一下""git下载项目""git拉下来""git看看我改了啥""git回退到上一个版本""git新建个分支搞新功能""git合并到主分支""git
容易踩的坑：
-
git checkout main或git switch main失败，报错：error: Your local changes to the following files would be overwritten by checkout—— 这就是 Git 在拦你，别硬切 - 用
git stash后没记清自己 stash 了什么，几天后git stash list看到一堆WIP on feature/xxx，根本分不清哪条是登录页样式、哪条是接口重试逻辑 - 误用
git stash pop导致冲突没处理完就继续写，后面git status显示一堆Unmerged paths
怎么让 stash 更可靠、可追溯？
别只敲 git stash。加参数和描述，成本极低，但后期排查效率翻倍：
- 用
git stash push -m "login: token刷新逻辑初稿"替代裸git stash，-m参数强制你思考这次 stash 的上下文 - 需要连未跟踪文件（比如临时生成的
mock-data.json或.env.local）一起存，加-u：git stash push -u -m "dev env + api mock" - 查看某次 stash 改了什么：
git stash show -p stash@{0}，比盲猜靠谱得多 - 恢复时别默认
pop，先apply，确认没问题再drop—— 防止恢复失败后 stash 被删，彻底丢内容
stash 不是万能的，这些情况它帮不上忙
如果你遇到的是下面这些，git stash 只是临时绕路，真正要解决的是协作流程或 Git 操作习惯问题：
- 远程
main分支已更新，你想把本地feature分支也同步过去 —— 这该用git rebase origin/main或git merge origin/main，不是 stash - 同事在同一个文件上改了不同行，你
git pull后出现冲突 —— stash 解不了合并冲突，得手动编辑、git add、git commit - 你 stash 之后切走修 bug，回来发现
git stash apply报冲突 —— 说明别人动过同一块代码，这时得先git diff对比，再决定是保留 stash 内容、还是放弃、还是手工合并
最常被忽略的一点：stash 栈是全局的，不是按分支隔离的。git stash list 显示的所有条目，你在任何分支都能看到、都能恢复。这意味着，如果你在多个分支来回切、反复 stash，栈会越来越长，而每一条的上下文又没写清楚，最后谁也救不了你。
