代码刚推到 GitHub，网站就报错；或者折腾了半天，发现三个版本以前反而最稳定。这时候很多新手第一反应是：把旧代码重新复制一遍。能用，但很笨，而且特别容易把文件漏掉。
GitHub 仓库回退到之前版本并不难，难的是选对方法。Git 里常见的 revert、reset 和 restore 看着像一家三兄弟，脾气却完全不同：一个撤销提交但保留历史，一个直接改写历史，一个只负责恢复文件。命令用错，轻则多出几个提交，重则把自己和同事的新代码一起送走。
先看答案：大多数人应该使用 git revert
| 你的真实需求 | 推荐方法 | 是否改写历史 | 风险 |
|---|---|---|---|
| 撤销已经推送到 GitHub 的错误提交 | git revert | 否 | 低，团队仓库首选 |
| 撤销一个已经合并的 Pull Request | GitHub 网页上的 Revert | 否 | 低 |
| 让整个分支彻底回到旧提交 | git reset --hard | 是 | 高 |
| 只恢复某个文件或目录 | git restore --source | 否 | 低 |
| 只想查看或下载旧代码 | GitHub 提交页面浏览或下载 | 否 | 几乎没有 |
Git 官方文档对三者的区分很明确：revert 会创建一个新提交来抵消旧提交；restore 用于恢复工作区或暂存区里的文件；reset 会移动分支指针，改变提交历史。仓库已经和别人共享时，优先选 revert，这是最不容易惹同事翻白眼的办法。
回退前先做这4步，别急着敲危险命令
下面示例默认分支名为 main。如果你的仓库使用 master 或其他名称，请替换成实际分支名。
git status
git fetch origin
git switch main
git log --oneline --decorate -10- 先看
git status：确认没有尚未提交的修改。Git 官方也提醒，执行git revert时工作树应保持干净。 - 拉取远程信息：
git fetch origin只更新远程状态，不会直接改你的文件。 - 确认当前分支：不要本来想回退测试分支，结果把
main动了手术。 - 找到目标提交：
git log --oneline左侧那串字符就是提交哈希，例如a1b2c3d。
不管选择哪一种方案，我都建议先创建一个保险分支：
git branch backup-before-rollback它相当于在动手前拍了一张快照。真回退错了，还能从这个分支把代码找回来。
方法一：用 git revert 撤销某次提交，最安全
假设错误提交的哈希是 a1b2c3d，执行：
git revert a1b2c3d
git push origin maingit revert 不会删除原提交，而是新建一个“反向提交”，把那次修改抵消掉。提交记录里既能看到当初做了什么，也能看到后来为什么撤销，审计清楚，团队协作也安全。Git 官方的 git-revert 文档也将它定义为通过新提交撤销已有提交的影响。
连续撤销多个提交
最容易理解的做法，是从最新的错误提交开始逐个撤销：
git revert 最新提交哈希
git revert 上一个提交哈希
git push origin main如果中途发生冲突，解决冲突并添加文件后运行：
git add .
git revert --continue发现方向错了，可以执行 git revert --abort，回到开始撤销之前的状态。别在冲突页面里一顿乱删，那通常是事故从“小问题”升级成“今晚别睡”的起点。
撤销合并提交要多看一眼
如果目标是一个 merge commit，常见命令是：
git revert -m 1 合并提交哈希这里的 -m 1 是指定第一父提交为主线，不是“撤销第一个提交”。合并结构复杂时不要照抄，先让熟悉仓库的人确认主线，否则后续再次合并同一分支时可能出现意外结果。
方法二：直接在 GitHub 网页撤销已合并的 Pull Request
如果错误代码是通过 Pull Request 合并进去的，而且你不想碰命令行，可以直接使用 GitHub 网页：
- 进入仓库，点击 Pull requests。
- 打开已经合并、需要撤销的 Pull Request。
- 在页面底部点击 Revert。
- GitHub 会创建一个新的撤销 Pull Request。
- 检查文件变化和自动测试，确认无误后再合并。
根据 GitHub 官方说明，这种操作会创建一个新 PR，用来撤销原来的合并提交，并且操作者需要仓库写入权限。如果页面没有 Revert 按钮，常见原因是权限不足、原 PR 不是在 GitHub 上完成合并，或者自动撤销会产生冲突。
方法三：用 reset –hard 让整个分支回到旧版本
这才是很多人理解的“真正回退”：让 main 分支指针直接回到某个旧提交，后面的提交从分支历史中消失。
git fetch origin
git switch main
git pull --ff-only origin main
git branch backup-before-hard-reset
git reset --hard 目标提交哈希
git push --force-with-lease origin main这套命令风险很高，只适合你完全了解后果的个人仓库，或者团队已经明确同意改写历史的场景。git reset --hard 会重置暂存区和工作区，目标提交之后对受 Git 跟踪文件所做的本地修改会被丢弃。Git reset 官方文档对此写得很直白。
推送时推荐 --force-with-lease，不要随手使用裸奔式的 --force。Git push 文档说明，--force-with-lease 会在远程分支仍处于预期状态时才允许覆盖；如果同事刚推了新代码，它通常会拒绝操作。它不是绝对保险，但至少比闭着眼睛强推文明得多。
另外，GitHub 的分支保护规则可能禁止强制推送。这不是 GitHub 故意跟你作对，而是在阻止一次可能无法挽回的事故。团队仓库遇到这种情况，应改用 git revert 和 Pull Request。
方法四：只把一个文件恢复到旧版本
如果只是某个配置文件、模板或插件文件改坏了，没必要让整个仓库坐时光机。使用：
git restore --source 目标提交哈希 -- 路径/文件名
git diff
git add 路径/文件名
git commit -m "Restore file from previous version"
git push origin mainGit restore 官方文档说明，--source 可以指定一个提交、分支或标签作为文件来源。这个操作不会自动移动分支历史，只是把旧内容取回当前工作区；确认差异后重新提交即可。
不会命令行，只想下载以前的代码怎么办？
- 打开 GitHub 仓库首页。
- 点击提交数量或 Commits，进入提交历史。
- 找到目标版本，点击对应的提交哈希。
- 选择浏览该提交中的文件。
- 通过 Code 下载 ZIP，或者复制该提交哈希后再交给技术人员处理。
需要注意：下载旧版本不等于仓库已经回退。它只是拿到一份历史代码，GitHub 上的 main 分支不会发生任何变化。把 ZIP 解压后直接覆盖生产网站也不值得鼓励，因为新旧版本可能存在数据库结构、依赖包和配置差异。
GitHub 回退成功，网站为什么还没恢复？
GitHub 管的是代码，不一定管理生产网站。仓库回退之后，还需要确认部署系统是否重新发布了目标分支。使用 GitHub Actions、Vercel、服务器脚本或其他自动部署工具时，要检查构建记录是否成功、环境变量是否存在、缓存是否清理。
如果仓库里放的是 WordPress 主题或插件，还要记住：Git 通常不会替你恢复数据库、媒体库、订单、文章和服务器配置。代码回到昨天，数据库仍然活在今天，两个时间线硬凑在一起，网站照样可能报错。
使用 SHOPAGG 搭建或托管 WordPress 独立站时，进行版本替换或重新部署前，可以先在控制台创建网站备份；如果需要把网站资产长期保存在本地，则使用“导出网站”获取整站源码和数据包。Git 负责代码版本，网站备份负责生产数据，两套保险别混成一套。
几个最常见的回退坑
- 没保存本地修改就执行
reset --hard：未提交内容可能直接丢失。 - 把提交哈希看错：回退前用
git show 提交哈希检查作者、日期和文件变化。 - 在团队主分支强推：可能覆盖其他人的新提交，优先改用
revert。 - 只回退代码，不处理数据库迁移：应用版本和数据库结构不匹配，照样无法运行。
- 误以为标签或 Release 会自动恢复线上版本：它们主要用于标记版本，是否部署取决于你的发布流程。
- 回退后不测试：至少检查构建、登录、核心页面、接口和依赖安装，不要看到命令没报红就宣布胜利。
如果你只记住一句话：公共仓库优先 git revert，单个文件使用 git restore，只有确定要改写历史时才碰 git reset --hard。Git 给了你时光机，也给了你把时间线剪断的剪刀。新手先学会倒车，再研究漂移。
