GitHub 如何从文件历史打开指定提交并恢复单个文件

README.md 被改动后，最稳妥的处理方式不是凭记忆重写，而是先在 GitHub 文件页打开历史记录，选中一个明确的提交，再核对那一版文件内容。下面用公开的 golang/go 仓库演示完整路径：从当前文件页进入 History，再打开指定提交的文件版本；这套方法适合核对单个文件，也不会触碰账号权限或提交操作。

先确认文件入口和当前分支

打开 golang/go 的 README.md 文件页。左侧文件树显示当前分支为 master，主区域顶部会显示文件名、最近一次提交和 History。本例选公开仓库，只读查看即可复现，不需要登录。

第1步：从文件页点击 History

路径是：仓库 Code → 文件树中的 README.md → 文件标题右侧的 History。不要先点顶部仓库级别的提交列表；文件页上的 History 会把范围限定为当前文件。

可见成功状态是：页面仍显示 README.md，顶部同时出现最近提交短 SHA 和 History。如果看到的是仓库首页，说明还没有进入文件级页面。

在 History 列表锁定目标提交

第2步：按提交信息和短 SHA 选择版本

进入 History 后，页面路径会变成仓库的 /commits/master/README.md。列表按日期分组，每条记录包含提交说明、作者、日期和短 SHA。本例选择 5e8a731，提交说明是“README: fix CC BY license name”。

可见成功状态是：面包屑明确写着 History for go / README.md，目标条目同时出现提交说明和 5e8a731。记下短 SHA 后，优先点击该条提交说明或短 SHA，不要凭日期猜版本。

打开指定提交并核对文件内容

第3步：查看提交版本，不要误点编辑

点击目标条目的提交说明，进入 /commit/5e8a731... 页面；在提交详情中再点击文件路径 README.md，或者直接打开该提交对应的文件 URL。页面顶部会显示提交短 SHA，文件工具栏保留 Raw、复制和下载入口。

可见成功状态有三项：分支选择器显示提交 SHA 而不是 master，提交说明与 History 中一致，文件正文也随该提交版本加载。此时点击 Raw 可以查看纯文本；如果只是恢复一段内容，复制 Raw 文本到本地文件，再由本地 Git 工作流提交，风险更低。

恢复前的三项结果核对

网页端能完成“找到哪一版”的确认，但它不会替你把任意历史内容安全写回当前分支。真正恢复时，建议把 Raw 内容保存到本地后执行差异比较，确认只改目标文件，再由已有的代码评审流程提交。

常见问题：历史文件核对时容易混淆的地方

History 和仓库首页的 Commits 有什么区别？

History 只筛选当前文件的变更记录；仓库首页的 Commits 展示整个仓库的提交。恢复单个文件时，优先使用文件页 History。

短 SHA 足够定位历史版本吗？

在当前仓库页面中，短 SHA 用于点击和识别很方便；需要写入脚本或审计记录时，使用提交页面展示的完整 SHA 更稳妥。

打开指定提交后能直接覆盖 master 吗？

本教程只做只读核验。打开旧提交不会自动修改当前分支；覆盖前应在本地比较差异，并按项目的评审流程提交。

最后确认：什么时候算找对了文件版本

当文件名、提交说明、SHA 和正文内容四项都能在同一条历史链路中对上，就可以把该提交作为恢复依据。把网页上的定位结果留给本地差异比较，既保留了版本证据，也避免在不清楚影响范围时直接改动线上分支。