尧图网页设计 
教程文档【免费下载链接】30-seconds-of-codeCoding articles to level up your development skills项目地址https://gitcode.com/gh_mirrors/30/30-seconds-of-code点击查看免费下载git log只能展示当前分支可达的提交而git rebase、git reset --hard、git commit --amend这类危险操作往往会悄悄改写或移走引用让旧提交从常规日志中消失。本文以 30-seconds-of-code 仓库的 Git 速查文档 content/snippets/git/s/view-undo-history.md 为主体讲解git reflog这条安全网如何记录每一次引用移动以及如何配合git reset把仓库精确恢复到过去的某个状态帮助你从容应对误操作。为什么git log会看不见你的历史git log展示的是当前分支可达的提交链它沿着HEAD一路向祖先追溯。一旦你执行了git rebase -i改写提交、git reset --hard回退指针、或git commit --amend修改提交信息旧的提交对象虽然仍残留在对象数据库里却不再被任何分支引用于是从git log中消失。这正是仓库文档中force-push-better-alternative.mdcontent/snippets/git/s/force-push-better-alternative.md所描述的场景作者在多年的git push --force使用中庆幸git reflog在极少数搞砸的情况下救了我。而view-undo-history.md开宗明义地指出Sometimes,git logdoesnt cut it, especially for commands that dont show up in your commit history. Fortunately, theres a way to view yourundo history.git reflogis basically your safety net after running scary commands likegit rebase.git reflogreference log记录的是引用reference的移动历史——它不仅列出你做过的提交还记录了每一次导致当前状态的动作checkout、commit、rebase、reset、merge 等。换言之它是一份操作流水账而git log只是一份结果快照。使用git reflog查看撤销历史查看撤销历史的最直接方式就是执行git reflog它会按时间倒序打印HEAD的引用日志git reflog # b6a4f9d6ff9 (HEAD - patch-1, origin/patch-1) HEAD{0}: Update docs # 3050fc0de HEAD{1}: rebase -i (finish): returning to refs/heads/patch-1 # 3050fc0de HEAD{2}: rebase -i (pick): Fix network bug # 93df3f495 (origin/patch-2) HEAD{3}: rebase -i (start): checkout origin/master # 69beaeabb HEAD{4}: rebase -i (finish): returning to refs/heads/patch-1读懂 reflog 的每一行逐字段解析上面这份输出可以完整还原一次交互式 rebase 的过程字段示例含义提交哈希b6a4f9d6ff9该操作发生时HEAD指向的提交引用位置HEAD{0}位置标记HEAD{0}是当前状态HEAD{n}是第 n 次之前的状态动作rebase -i (pick)/rebase -i (start)触发引用移动的操作类型说明returning to refs/heads/patch-1动作细节如从哪个分支开始、回到哪个分支从上面的输出可以还原出操作者先基于origin/master开始交互式 rebaseHEAD{3}逐个 pick 提交HEAD{2}rebase 结束后回到patch-1分支HEAD{1}最后提交了 Update docsHEAD{0}。整个操作链一目了然即使中间某一步改写失败你也知道该回到哪个位置。常用变体与筛选除了直接运行git reflog你还可以通过参数和子命令细化查看# 只显示当前分支的 reflog等价于 git reflog show HEAD git reflog show # 查看其他分支或引用的 reflog git reflog show patch-1 # 指定分支 git reflog show origin/master # 远程跟踪分支 # 只看最近 N 条记录 git reflog -5 # 简化输出每行只显示一行概要 git reflog --oneline # 按日期过滤适合排查几天前发生了什么 git reflog --dateiso --since3 days ago[!NOTE] reflog 并非永久保留。它由 Git 的垃圾回收git gc按gc.reflogExpire配置清理默认过期时间为90 天可通过git config gc.reflogExpire查看或修改。如果误操作发生在很久以前reflog 中的记录可能已被清理此时可以尝试git fsck --lost-found见 content/snippets/git/s/find-lost-files.md从悬空对象中恢复。用git reset回到指定状态在 reflog 中找到目标提交后就可以用git reset把当前分支指针移回去。仓库文档给出的核心用法git reset --hard 3050fc0de # Go back to the commit with the given hash三种 reset 模式的取舍git reset默认执行混合模式配合不同参数会以不同方式处理工作区与暂存区。参考仓库中同主题文档 content/snippets/git/s/rewind-to-commit.md可以这样理解三种模式# 语法: git reset [--soft | --mixed | --hard] commit git reset --soft 3050fc0 # 仅移动分支指针保留暂存区与工作区相当于取消提交但保留改动 git reset 3050fc0 # 默认--mixed移动指针并取消暂存改动保留在工作区 git reset --hard 3050fc0 # 移动指针同时丢弃暂存区与工作区的改动破坏性操作谨慎使用按提交数量回退HEAD~n语法如果不想查哈希也可以用HEAD~n按数量回退# 语法: git reset [--hard] HEAD~n git reset HEAD~5 # 回退 5 个提交改动保留在工作区 git reset --hard HEAD~3 # 回退 3 个提交同时删除改动在rewind-to-commit.md中作者特别提示了--hard的破坏性并明确指向本文主题作为补救手段The--hardflag is considered a destructive action, which means you should be extra careful when using it. If things go wrong, you might be able to recover your changes by viewing the reference log.这形成了一个完整的闭环--hard造成损失 → reflog 依然记录着 reset 前的HEAD位置 → 再用git reset --hard恢复到 reflog 中的那个位置实现撤销撤销。实战从一次搞砸的 rebase 中恢复把本文的两个命令串起来就是一个完整的恢复流程。假设你执行git rebase -i origin/master时误删了提交且 rebase 已经完成# 1. 查看撤销历史定位 rebase 开始前的状态 git reflog # 3050fc0de HEAD{1}: rebase -i (finish): returning to refs/heads/patch-1 # 93df3f495 (origin/patch-2) HEAD{2}: rebase -i (start): checkout origin/master # 2. 确认目标提交内容无误可选 git show 93df3f495 # 3. 回到 rebase 开始前的提交 git reset --hard 93df3f495 # HEAD is now at 93df3f495 ... # 4. 再次确认状态 git reflog -1 # 93df3f495 HEAD{0}: reset: moving to 93df3f495reflog 中新增的reset: moving to 93df3f495记录表明恢复成功而这次恢复动作本身也会被记录下来形成可继续追溯的历史。让 reflog 成为日常习惯这份仓库的 Git 速查集为 reflog 配套了多个上下游知识点组合使用可以让恢复能力更完整设置别名随手可查aliases.md 中推荐了rl reflog别名把长命令缩成一个两个字母的快捷键降低使用门槛强制推送前先留后路force-push-better-alternative.md 介绍了git push --force-with-lease这种更安全的替代方案但即便如此reflog 依然是你最后的保险对象已丢失时find-lost-files.md 中的git fsck --lost-found能扫描悬空对象与 reflog 形成互补已推送的提交不要 reset如果改动已经推送到远程且被他人拉取undo-commit-without-rewriting-history.md 建议改用git revert创建反向提交而不是改写历史rebase 是 reflog 的高频触发源interactive-rebase.md 详解的git rebase -i每次 pick、squash、drop 都会写进 reflog理解了 rebase 内部动作也就理解了 reflog 输出中的rebase -i (start)/rebase -i (finish)等条目。小结git reflog与git reset是一对互补的安全工具前者告诉你发生过什么、现在能去哪后者负责真正到达那里。把git reflog培养成搞砸之后的第一个反应配合git reset --hard hash精确回退你几乎可以撤销任何本地误操作——这正是 30-seconds-of-code 这份 Git 速查文档想传达的核心能力。赞分享教程文档【免费下载链接】30-seconds-of-codeCoding articles to level up your development skills项目地址https://gitcode.com/gh_mirrors/30/30-seconds-of-code点击查看免费下载相关推荐用 git revert 撤销提交而不重写历史30-seconds-of-code 中的安全回滚指南用 git revert 撤销提交而不重写历史30 seconds of code 中的安全回滚指南 本文以 30 seconds of code 仓库的 G教程文档Git提交历史重写isomorphic-git中的交互式rebase实现Git提交历史重写isomorphic git中的交互式rebase实现 在日常开发中我们经常需要整理提交历史使其更加清晰易读。无论是合并多个小提交还是开发工具RevokeMsgPatcher技术深度解析Windows平台即时通讯消息保留解决方案完全手册RevokeMsgPatcher技术深度解析Windows平台即时通讯消息保留解决方案完全手册 消息撤回功能在现代即时通讯软件中广泛存在其设计初衷是纠正误发桌面应用即时通讯上一篇hls.js 发布流程指南从 Git Tag 到 npm / GitHub Release 的自动化实践下一篇零代码AI入门3分钟掌握Teachable Machine图像识别技术创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 用 `git reflog` 查看 Git 撤销历史：重建被重写或被删除的提交状态
教程文档【免费下载链接】30-seconds-of-codeCoding articles to level up your development skills项目地址https://gitcode.com/gh_mirrors/30/30-seconds-of-code点击查看免费下载git log只能展示当前分支可达的提交而git rebase、git reset --hard、git commit --amend这类危险操作往往会悄悄改写或移走引用让旧提交从常规日志中消失。本文以 30-seconds-of-code 仓库的 Git 速查文档 content/snippets/git/s/view-undo-history.md 为主体讲解git reflog这条安全网如何记录每一次引用移动以及如何配合git reset把仓库精确恢复到过去的某个状态帮助你从容应对误操作。为什么git log会看不见你的历史git log展示的是当前分支可达的提交链它沿着HEAD一路向祖先追溯。一旦你执行了git rebase -i改写提交、git reset --hard回退指针、或git commit --amend修改提交信息旧的提交对象虽然仍残留在对象数据库里却不再被任何分支引用于是从git log中消失。这正是仓库文档中force-push-better-alternative.mdcontent/snippets/git/s/force-push-better-alternative.md所描述的场景作者在多年的git push --force使用中庆幸git reflog在极少数搞砸的情况下救了我。而view-undo-history.md开宗明义地指出Sometimes,git logdoesnt cut it, especially for commands that dont show up in your commit history. Fortunately, theres a way to view yourundo history.git reflogis basically your safety net after running scary commands likegit rebase.git reflogreference log记录的是引用reference的移动历史——它不仅列出你做过的提交还记录了每一次导致当前状态的动作checkout、commit、rebase、reset、merge 等。换言之它是一份操作流水账而git log只是一份结果快照。使用git reflog查看撤销历史查看撤销历史的最直接方式就是执行git reflog它会按时间倒序打印HEAD的引用日志git reflog # b6a4f9d6ff9 (HEAD - patch-1, origin/patch-1) HEAD{0}: Update docs # 3050fc0de HEAD{1}: rebase -i (finish): returning to refs/heads/patch-1 # 3050fc0de HEAD{2}: rebase -i (pick): Fix network bug # 93df3f495 (origin/patch-2) HEAD{3}: rebase -i (start): checkout origin/master # 69beaeabb HEAD{4}: rebase -i (finish): returning to refs/heads/patch-1读懂 reflog 的每一行逐字段解析上面这份输出可以完整还原一次交互式 rebase 的过程字段示例含义提交哈希b6a4f9d6ff9该操作发生时HEAD指向的提交引用位置HEAD{0}位置标记HEAD{0}是当前状态HEAD{n}是第 n 次之前的状态动作rebase -i (pick)/rebase -i (start)触发引用移动的操作类型说明returning to refs/heads/patch-1动作细节如从哪个分支开始、回到哪个分支从上面的输出可以还原出操作者先基于origin/master开始交互式 rebaseHEAD{3}逐个 pick 提交HEAD{2}rebase 结束后回到patch-1分支HEAD{1}最后提交了 Update docsHEAD{0}。整个操作链一目了然即使中间某一步改写失败你也知道该回到哪个位置。常用变体与筛选除了直接运行git reflog你还可以通过参数和子命令细化查看# 只显示当前分支的 reflog等价于 git reflog show HEAD git reflog show # 查看其他分支或引用的 reflog git reflog show patch-1 # 指定分支 git reflog show origin/master # 远程跟踪分支 # 只看最近 N 条记录 git reflog -5 # 简化输出每行只显示一行概要 git reflog --oneline # 按日期过滤适合排查几天前发生了什么 git reflog --dateiso --since3 days ago[!NOTE] reflog 并非永久保留。它由 Git 的垃圾回收git gc按gc.reflogExpire配置清理默认过期时间为90 天可通过git config gc.reflogExpire查看或修改。如果误操作发生在很久以前reflog 中的记录可能已被清理此时可以尝试git fsck --lost-found见 content/snippets/git/s/find-lost-files.md从悬空对象中恢复。用git reset回到指定状态在 reflog 中找到目标提交后就可以用git reset把当前分支指针移回去。仓库文档给出的核心用法git reset --hard 3050fc0de # Go back to the commit with the given hash三种 reset 模式的取舍git reset默认执行混合模式配合不同参数会以不同方式处理工作区与暂存区。参考仓库中同主题文档 content/snippets/git/s/rewind-to-commit.md可以这样理解三种模式# 语法: git reset [--soft | --mixed | --hard] commit git reset --soft 3050fc0 # 仅移动分支指针保留暂存区与工作区相当于取消提交但保留改动 git reset 3050fc0 # 默认--mixed移动指针并取消暂存改动保留在工作区 git reset --hard 3050fc0 # 移动指针同时丢弃暂存区与工作区的改动破坏性操作谨慎使用按提交数量回退HEAD~n语法如果不想查哈希也可以用HEAD~n按数量回退# 语法: git reset [--hard] HEAD~n git reset HEAD~5 # 回退 5 个提交改动保留在工作区 git reset --hard HEAD~3 # 回退 3 个提交同时删除改动在rewind-to-commit.md中作者特别提示了--hard的破坏性并明确指向本文主题作为补救手段The--hardflag is considered a destructive action, which means you should be extra careful when using it. If things go wrong, you might be able to recover your changes by viewing the reference log.这形成了一个完整的闭环--hard造成损失 → reflog 依然记录着 reset 前的HEAD位置 → 再用git reset --hard恢复到 reflog 中的那个位置实现撤销撤销。实战从一次搞砸的 rebase 中恢复把本文的两个命令串起来就是一个完整的恢复流程。假设你执行git rebase -i origin/master时误删了提交且 rebase 已经完成# 1. 查看撤销历史定位 rebase 开始前的状态 git reflog # 3050fc0de HEAD{1}: rebase -i (finish): returning to refs/heads/patch-1 # 93df3f495 (origin/patch-2) HEAD{2}: rebase -i (start): checkout origin/master # 2. 确认目标提交内容无误可选 git show 93df3f495 # 3. 回到 rebase 开始前的提交 git reset --hard 93df3f495 # HEAD is now at 93df3f495 ... # 4. 再次确认状态 git reflog -1 # 93df3f495 HEAD{0}: reset: moving to 93df3f495reflog 中新增的reset: moving to 93df3f495记录表明恢复成功而这次恢复动作本身也会被记录下来形成可继续追溯的历史。让 reflog 成为日常习惯这份仓库的 Git 速查集为 reflog 配套了多个上下游知识点组合使用可以让恢复能力更完整设置别名随手可查aliases.md 中推荐了rl reflog别名把长命令缩成一个两个字母的快捷键降低使用门槛强制推送前先留后路force-push-better-alternative.md 介绍了git push --force-with-lease这种更安全的替代方案但即便如此reflog 依然是你最后的保险对象已丢失时find-lost-files.md 中的git fsck --lost-found能扫描悬空对象与 reflog 形成互补已推送的提交不要 reset如果改动已经推送到远程且被他人拉取undo-commit-without-rewriting-history.md 建议改用git revert创建反向提交而不是改写历史rebase 是 reflog 的高频触发源interactive-rebase.md 详解的git rebase -i每次 pick、squash、drop 都会写进 reflog理解了 rebase 内部动作也就理解了 reflog 输出中的rebase -i (start)/rebase -i (finish)等条目。小结git reflog与git reset是一对互补的安全工具前者告诉你发生过什么、现在能去哪后者负责真正到达那里。把git reflog培养成搞砸之后的第一个反应配合git reset --hard hash精确回退你几乎可以撤销任何本地误操作——这正是 30-seconds-of-code 这份 Git 速查文档想传达的核心能力。赞分享教程文档【免费下载链接】30-seconds-of-codeCoding articles to level up your development skills项目地址https://gitcode.com/gh_mirrors/30/30-seconds-of-code点击查看免费下载相关推荐用 git revert 撤销提交而不重写历史30-seconds-of-code 中的安全回滚指南用 git revert 撤销提交而不重写历史30 seconds of code 中的安全回滚指南 本文以 30 seconds of code 仓库的 G教程文档Git提交历史重写isomorphic-git中的交互式rebase实现Git提交历史重写isomorphic git中的交互式rebase实现 在日常开发中我们经常需要整理提交历史使其更加清晰易读。无论是合并多个小提交还是开发工具RevokeMsgPatcher技术深度解析Windows平台即时通讯消息保留解决方案完全手册RevokeMsgPatcher技术深度解析Windows平台即时通讯消息保留解决方案完全手册 消息撤回功能在现代即时通讯软件中广泛存在其设计初衷是纠正误发桌面应用即时通讯上一篇hls.js 发布流程指南从 Git Tag 到 npm / GitHub Release 的自动化实践下一篇零代码AI入门3分钟掌握Teachable Machine图像识别技术创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考