GitHub Desktop 怎样恢复未提交的丢失分支提交

GitHub Desktop 里看不到刚才的分支提交时，先不要删除仓库、重新克隆或点击会覆盖工作区的操作。恢复要先分层判断：仍在 Changes 里的改动属于未提交内容，Stashed Changes 里的内容可以直接 Restore；如果提交已经写入本地 Git，但分支指针被移动或分支被删掉，则应从 reflog 找到哈希，再创建一个新的恢复分支。

官方地址：https://desktop.github.com/

下面的路径围绕 GitHub Desktop 的本地仓库展开。界面插图是原创操作示意图，不是软件截图；命令只用于找回本地提交对象，不会替你判断没有保存过的文件。

先判断内容到底丢在哪一层

打开仓库后先看左侧的 Changes。如果文件仍出现在这里，说明内容还在工作区，优先把文件复制到仓库外的临时目录，或先完成一次本地提交。不要为了“刷新分支”而丢弃改动。

如果 Changes 为空，再点开 Stashed Changes。这里的条目可以用 Restore 放回当前分支；恢复前要确认当前分支就是产生 stash 的分支，或者先切到目标分支。GitHub Desktop 的 stash 只适合保存已经写入文件、但暂时不想提交的改动。

最后查看 History。能在历史中看到提交，说明它还挂在某个可见分支上；看不到并不代表对象立刻消失，可能只是分支指针不再指向它。此时不要把“未提交的改动”和“已经提交但分支丢失”混为一谈。

从 Repository 菜单打开命令行

在 GitHub Desktop 顶部菜单选择 Repository → Open in command line，让命令行进入当前仓库目录。先执行下面的只读命令，查看 HEAD 和分支移动记录：

# 查看 HEAD、分支切换和最近提交，先定位可能的提交哈希
git reflog --date=local

# 用短哈希查看提交内容，确认它确实属于要恢复的工作
git show --stat --oneline a1b2c3d

reflog 的每一行都包含一个短哈希和动作说明。优先找带有 commit: 的记录，再结合时间、提交说明和文件变更确认目标。这里的 a1b2c3d 只是示例占位符，实际使用时替换成你查到的哈希。

找到提交后先创建恢复分支

不要直接把当前主分支强行 reset 到未知位置。用目标哈希创建一个新分支，给原分支保留回退空间：

# 从已确认的提交创建独立恢复分支，不改写现有分支指针
git switch -c recovery/lost-work a1b2c3d

# 确认当前分支和提交位置，避免误把恢复结果留在 detached HEAD
git status --short --branch
git log -1 --oneline

回到 GitHub Desktop 后，在 Current Branch 中应能看到新建的恢复分支；再打开 History，检查提交说明和变更文件。若内容正确，可以继续在该分支上提交修正，之后再决定是否点击 Publish branch。

三种情况不要用同一套恢复动作

恢复后怎样确认没有把问题扩大

验收时只检查三件事：Current Branch 是否是恢复分支；History 中的目标提交是否存在；Changes 中是否出现预期文件。确认无误后再提交新增修正，并把恢复分支发布到远端。若目标提交涉及敏感文件，先在 Changes 中审阅差异，不要因为恢复成功就立即公开。

如果 reflog 中只有分支切换，没有目标 commit: 记录，通常意味着内容从未提交到这个本地仓库，或记录已被清理。GitHub Desktop 能恢复的是工作区、stash 或仍存在的 Git 对象；它不能凭空重建没有保存过的内容。

常见问题

GitHub Desktop 能直接恢复已删除分支吗？

如果删除前的提交仍在本地对象库中，可以用 reflog 找到提交哈希，再创建恢复分支；如果对象已被清理，则需要从远端、备份或编辑器历史寻找来源。

为什么不建议直接 reset 当前分支？

reset 会改变当前分支指针，容易把仍可见的工作状态混在恢复动作里。新建恢复分支更容易比较、审阅和回退。

没有提交的文件能从 reflog 找回吗？

不能。reflog 记录的是引用移动和提交对象，不是所有编辑器内存或未保存文件。未提交改动应先从 Changes、stash、系统回收站或编辑器本地历史排查。

一句话总结：先保护 Changes，再查看 Stashed Changes 和 History；只有确定提交对象已经存在但脱离分支时，才用 reflog 找哈希、创建恢复分支并在 GitHub Desktop 中验收。