GitHub Desktop 切换分支前怎么暂存未提交修改

在 GitHub Desktop 里切换分支前，如果当前工作区还有不想马上提交的修改，可以先暂存，再去处理另一条分支。最短路径是：打开 Changes，右键变更文件标题，选择 Stash All Changes；任务完成后回到原分支，打开 Stashed Changes，点击 Restore。这样既不会为了切分支制造临时提交，也不会把未完成的代码混到另一条分支。

一、先确认当前分支和未提交文件

先看顶部仓库栏的 Current Branch，记住当前分支名称，例如 feature/profile-card。再打开左侧的 Changes，确认列表里的文件确实是这次尚未完成的工作。没有保存到磁盘的编辑内容不会按已保存文件的方式出现在变更列表中，所以先回到编辑器保存文件。

这一步还要排除不想带走的文件。GitHub Desktop 的暂存动作面向当前这组未提交修改，不能把它当成“只暂存某一个勾选文件”的精细分组工具。确认无误后再继续。

二、从 Changes 面板暂存全部修改

在 Changes 面板中找到变更文件列表上方的标题，例如 2 changed files。右键这个标题，在菜单中选择 Stash All Changes。这个入口不是顶部的提交按钮，也不是分支菜单里的临时选项，操作重点是对变更文件标题打开上下文菜单。

选择后，原来的文件差异会暂时从工作区移开，界面会显示与暂存内容相关的状态，而不是继续列出刚才那两份未提交文件。看到工作区不再显示这组修改，再进行分支切换；如果文件仍然出现在 Changes 列表，先不要切换，重新检查右键目标是否是变更文件标题。

三、切换到需要处理的分支

确认工作区已经清爽后，点击顶部 Current Branch，从分支列表选择临时要处理的目标分支，再点击切换按钮。GitHub Desktop 在存在未提交修改时通常会让你决定保留、带到新分支或先处理修改；现在因为修改已经被 stash，切换的前置冲突就被移除了。

切换后先看一次 Changes，确保临时分支没有出现原分支的文件。完成临时修复、查看代码或提交独立工作后，再按同样的分支入口回到产生这组 stash 的原分支。

四、回到原分支恢复暂存内容

回到原分支后，打开左侧 Changes。如果当前分支对应一组暂存内容，界面会出现 Stashed Changes。点击它查看暂存摘要，再在右侧暂存区域点击 Restore。恢复完成后，原先的文件应该重新回到普通的 Changes 列表，文件差异也可以继续编辑。

确认文件名和差异内容都回来了，再继续开发或提交。恢复不是提交动作，仓库仍然处于未提交状态；如果此时决定把工作固定下来，还需要填写提交信息并执行正常的 commit。

五、一次暂存只能解决一组临时现场

尤其要注意，GitHub Desktop 的这个入口一次只能暂存一组修改。新的 stash 可能覆盖你对“多组暂存”的预期，因此需要并行保留多个工作现场时，使用专用分支或 worktree 更稳妥。

相关问题

暂存后能直接切换到任意分支吗？

通常可以，但仍应先确认 Changes 已经清空，并在目标分支检查没有意外的本地修改。恢复时回到产生这组 stash 的原分支，再从 Stashed Changes 执行 Restore。

找不到 Stashed Changes 怎么办？

先检查当前分支是不是产生 stash 的原分支，再确认暂存动作确实完成。如果原分支名称记错，先从 Current Branch 逐个确认；如果工作区本来就没有已保存的未提交文件，也不会出现可恢复的暂存内容。