授权与合规声明本文全部操作对象均为自建隔离靶场本机容器或隔离虚拟机涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离不含任何攻击步骤、利用载荷与绕过手法请勿将文中环境指向任何非自有系统。一、场景与结论先行1.1 三个很常见的现场在靶场里跟着教程改配置几乎每个初学者都会撞上同一堵墙手比脑子快改完才发现不对劲。第一种现场文件改乱了想让它回到刚才的样子。教程让你改一处配置你顺手多改了几行回头再读原文已经记不清原本写的是什么。第二种现场已经git add了突然发现加错了。改动本身没错是你不该把这几个文件纳入这一次提交。第三种现场提交已经落下才发现这一提交不该要。可能是把测试用的临时改动一起提交了也可能是那几行调完忘了删。三种现场看起来都叫改坏了但它们坏在不同的层能用的补救手段也完全不同。混为一谈的常见后果是本来一条只还原工作区的命令就能解决的事你却用了更重的那一招把本来还想留着的东西一起抹掉了。1.2 先问自己三句话在敲任何一条命令之前先停下来回答三句话我改的是什么是一个文件、一组文件还是整个目录改动落在哪一层只在工作区里还是已经进了索引提交了没有是还没提交还是提交已经落下了这三句问完该用哪张网基本就定了。本文先把答案放在下面这张表里后面几章再逐个展开。你的处境改动落在了该动哪张网文件改乱了还没add工作区还原工作区已经add还没提交索引还原索引提交已落下想撤掉本地提交回退提交提交撤过头了本地提交历史先看引用日志reflog1.3 本文覆盖什么明确不覆盖什么先说清边界本文只覆盖工作区、索引、本地提交这三层。这三层都在你自己的机器上动作的后果也只落在你自己的机器上所以它属于环境可恢复性这件事而不是 Git 的全套教程。不覆盖的部分同样要说清分支策略不写协作流程不写远端仓库不写。涉及多人、涉及推送、涉及远程分支的操作代价和判断与本地完全不同不该和本地改坏了混在一起讲。本文也不展开任何与抓取、请求构造相关的内容所有操作对象都是自建隔离靶场里的本地代码。本章可以带走的一句先分清改了什么、改到哪一层、提交了没有再决定用哪张网——顺序错了救得越狠、丢得越多。二、先看清三种状态2.1 只读三连status 与 diff改坏之后最危险的动作是凭记忆立刻敲一条会改变状态的命令。更稳的做法是先用只读命令把现状看清楚。⚠️代码待验证gitstatusgit status回答的是改动落在哪一层哪些改动已经进了索引准备被提交哪些还只在工作区。⚠️代码待验证gitdiffgitdiff--stagedgit diff看的是工作区与索引之间的差异也就是改了但还没add的那部分git diff --staged看的是索引与HEAD之间的差异也就是已经add、即将进入下一次提交的那部分。另外还有git status --short用短格式把同一件事列得更紧凑。这几条命令的共同点是只读不改变任何状态。之所以反复强调这一点它们是你判断该用哪张网的唯一依据。看不清就动手等于闭着眼睛拆线。2.2 三张网的靶子工作区、索引、已提交要把三张网用对得先知道它们各自的靶子是什么。工作区你眼下能直接打开、编辑的那份文件。它是最外、最容易被改坏的一层。索引也叫暂存区。它是你为下一次提交准备的候选清单。git add做的事情就是把工作区的某个改动放进索引。已提交提交落下之后改动就写进了本地仓库的历史。这一层的改动不再是文件内容而是一条一条的提交记录。一层比一层深一层比一层难改但同时也一层比一层有据可查。工作区里的改动一旦被覆盖就没了索引里的内容HEAD里通常还有一份而提交即使被回退reflog 里往往还留着痕迹见第六章。换个说法这三张网并不是三个并列的工具而是三个深度不同的入口。你在哪一层动手就决定了另外两层受不受影响。所谓判断该用哪张网本质上就是判断这一次我希望影响几层。想清楚这一点再看命令的选项选项就不再是一堆记不住的开关而是一句句我要动到这一层为止的声明。层你怎么把它推开出问题时靠什么救工作区直接编辑文件还原工作区索引git add还原索引已提交git commit回退提交、引用日志2.3 一个容易忘的前提改动得先被 Git 看见这里有个前提值得单独提一句。上面三张网只对已被跟踪的路径生效。一个从来没被git add过、也不在任何提交里的新文件属于未跟踪文件——它不在三张网的常规靶子里。这不是文字游戏。后面讲--hard时会看到未跟踪文件恰恰是可能被一并覆盖的那一类。所以在你动手之前先数一遍我现在改的是被跟踪的文件还是新加的文件用只读命令把两类分开列出来再决定下一步。本章可以带走的一句工作区、索引、已提交是三个不同的层git status先告诉你改动落在哪一层再谈用哪张网。三、第一张网还原工作区3.1 git restore 到底做什么官方对git restore的 NAME 行写得很直白“git-restore - Restore working tree files”台账 G01。它的作用是用某个恢复源里的内容还原工作树中指定的路径台账 G01。注意这里的措辞它还原的是工作树中指定的路径不是整棵树。也就是说你给什么路径它动什么路径不给它不会自己扩大范围。这一点对只救坏掉的那一个文件很重要。⚠️代码待验证gitrestore -- path/to/file这条命令的语义是从默认的恢复源里把path/to/file的内容取回来覆盖掉工作区里现在这份。给路径时用--把路径和选项隔开可以避免路径名与选项名撞车。3.2 默认从哪儿还原这是本章最容易搞错的一点。官方给了一条很清楚的默认规则台账 G03给了--staged内容从HEAD还原否则内容从索引index还原。换句话说git restore不带--staged时它的默认恢复源是索引不是HEAD。这正好解释了初学者最常见的困惑“我明明想恢复成上次提交的样子怎么回来的却是我刚刚add进去的那一版”——因为你add之后索引里已经是新版本了从索引还原拿回来的自然是新的那一份。这条规则值得多念两遍因为它同时决定了两件事一是撤销 add该用哪个开关二是恢复成提交里的样子要不要额外指定源。把这两件事都挂在默认源这一条规则上是这一族命令最好记的地方。如果你确实想从某一次提交还原官方给的答案是--source台账 G03。它允许指定从其他提交还原而不是从默认的索引或HEAD还原。⚠️代码待验证gitrestore--sourceHEAD -- path/to/file这里--source后面给哪个提交由你按现场决定写HEAD只是从最近一次提交取这个最常见的用法。3.3 一个必须知道的后果路径可能被移除还有一条后果很多人第一次遇到会吓一跳。官方原文说得很明确若某路径已被跟踪、但在恢复源里不存在它会被移除以与恢复源一致台账 G01。把这句话翻译成现场如果这个文件是你新加的、并且已经进了索引而你要还原的那个源里根本没有它那么还原之后这个文件会从工作区消失。它不是被改回旧内容而是被直接拿掉了。所以还原工作区之前先回答一个问题我要还原的源里到底有没有这个路径如果这个文件是你刚建的、还没来得及提交那么它很可能不在源里还原就等于删掉它。真要在这种时候动手先把它复制一份出去再说。本章可以带走的一句git restore默认从索引还原、给了--staged才从HEAD还原源里没有的已跟踪路径会被移除动手前先确认它在不在源里。四、第二张网还原索引4.1--staged动的是哪一层第一张网管的是工作区第二张网管的是索引。同一族命令靠--staged这个开关切换靶子。官方说明该命令也可用于用--staged还原索引中的内容台账 G02。结合上一章的默认规则台账 G03git restore --staged的完整含义是以HEAD为源把索引还原成HEAD的样子。这正好对上初学者嘴里那句撤销 add。撤销 add 到底撤到哪一层答案是它只动索引不动工作区。你add进去的内容从索引里退出来但你手里的文件一个字都没变——改动还在只是不再是即将提交的状态。⚠️代码待验证gitrestore--staged-- path/to/file这里的代价很低索引被改工作区不动所以文件内容不会丢。这也是它比直接还原工作区更保险的地方。4.2 先想清楚你要的是哪一半这里有个很实用的分辨法。git add做的事情是把工作区的改动搬进索引所以它有两个端点起点是工作区终点是索引。想反过来就要先问自己我到底想 undo 哪一半你的意图该动哪一层结果不想让它进这次提交但文件要保持改后的样子只还原索引改动退回工作区连文件内容也不要这次改动还原工作区文件回到还原源的样子两层都要回到同一个源两层一起还原工作区与索引一致第一行是最常见的诉求也是最容易被做错的一行很多人明明只想退出这次提交却顺手把工作区也还原了结果文件改动也跟着没了。4.3 两层一起还原如果两层都要动官方给了组合方式--staged --worktree可同时还原工作树与索引台账 G02。⚠️代码待验证gitrestore--staged--worktree-- path/to/file代价要说清这一步是两层一起覆盖。工作区里现在这份内容会被还原源的版本盖掉索引也会同步过去。执行之前先确认工作区里没有你还想留下的东西——尤其是那些只存在于工作区、还没进过索引的改动它们一旦被覆盖就找不回来了。本章可以带走的一句--staged只动索引、不动工作区所以撤销 add不会弄丢你手里的文件但只要加上--worktree工作区里那份就会被覆盖动手前先确认它没有你还想留的内容。五、第三张网reset 的三档5.1 默认那一档--mixed前两张网都在文件层面第三张网进到了提交层面这就是git reset。它有三种模式mode默认是--mixed台账 G04。--mixed的行为官方给了三个要点台账 G04保持工作目录不变把索引更新为与新HEAD一致因此不会有东西处于已暂存状态。把这三句连起来读--mixed的效果是你的文件一个字不动但索引被清空到与目标HEAD一致。这也是它成为默认档的原因——在三种模式里它对文件内容的破坏最小。5.2--soft与--hard一个几乎不动一个动得最多--soft是三者里最轻的官方说它工作树文件与索引都不动台账 G04。官方还给了一个典型用法在没有已暂存改动时git reset --soft HEAD~5之后再git commit可以把最近 5 次提交合并为 1 次台账 G04。注意这里的关键点它只移动分支顶端文件内容原封不动。改的只是这条提交线画到哪里不是文件长什么样。--hard则是另一个极端。官方给的行为是台账 G04用commit的版本覆盖所有文件与目录并且可能覆盖未跟踪文件不在commit中的已跟踪文件会被移除使工作树与commit一致同时更新索引以匹配新HEAD。这里必须把人话说透--hard不是一条可以随手用的后悔药。它一次同时动三样东西——工作树里的文件、不在目标提交里的已跟踪文件、以及索引。更关键的是那句可能覆盖未跟踪文件如果你工作区里有一批刚建、还没提交过的新文件它们有可能在这一次操作里被一起抹掉而这类文件在 Git 里本来是没有历史可回的。所以本文不给出一条可以直接照抄去执行的--hard示例。真要走到这一步正确的顺序是先用只读命令确认工作区里没有未跟踪文件有的话先把它们复制出去再确认本次要去的那个commit就是你想要的状态最后才执行。换个角度理解这件事--soft与--mixed动的都是书签和清单只有--hard会真去动文件。文件一旦被覆盖Git 里就没有第二份可回如果它还是未跟踪文件连历史都没有可回。这就是为什么本章把它单拎出来讲了这么长。5.3 三档放在一起看把三档并排摆开差别就清楚了。模式工作树文件索引分支顶端是否可能波及未跟踪文件--soft不动不动移动否--mixed默认不动更新为与新HEAD一致移动否--hard用commit覆盖更新为新HEAD移动是还有两种模式值得提一句。--merge的行为是重置索引并更新工作树中在commit与 HEAD 之间有差异的文件但保留索引与工作树之间的未暂存改动若某文件在commit与索引之间不同、且存在未暂存改动reset 会被中止台账 G05。本文只用这一条已核口径不展开其他模式。最后一条与反悔直接相关执行 reset 之前ORIG_HEAD被设为当前分支的顶端台账 G06。也就是说在 reset 动作发生之前Git 先替你记下了一个原来的位置。这条记下来有什么用第六章接着讲。完整版环境对照表靶场里改配置改出问题只是时间早晚的事。这份对照表按平台列了靶场环境的可行路径与推荐做法配合本文回到已知状态这条思路一起用更顺手。放在资料包里扫码即可获取本章可以带走的一句--soft只移动分支顶端、--mixed默认额外清空索引、--hard连工作树一起覆盖且可能波及未跟踪文件——三档代价差得很远选之前先想清楚要动到哪一层。六、提交之后还能不能救reflog6.1 reflog 记录的是什么前面三张网都假设改动还没走远。那如果提交已经落下甚至 reset 也已经执行过还能不能救这就轮到引用日志出场了。官方的定义是参考日志reflogs记录分支顶端与其他引用在本地仓库中被更新的时间台账 G07。注意这句话里的两个限定词分支顶端与其他引用、本地仓库。reflog 记的是引用什么时候动过而不是文件内容怎么变过。git reflog show是默认子命令显示所给引用默认HEAD的日志台账 G08。官方还说明reflog覆盖所有近期动作此外HEAD reflog 还记录分支切换台账 G08。它本质上是一个别名git reflog show等价于git log -g --abbrev-commit --prettyoneline台账 G08。⚠️代码待验证gitrefloggitreflog show两条命令都是只读的不会改变任何状态可以放心先看一眼。6.2HEAD{2}怎么读reflog 里那一串HEAD{n}第一次看很容易发懵。官方给的解释很直观HEAD{2}表示HEAD 两次移动之前所在的地方台账 G07。把它拆开读HEAD是在问HEAD 曾经在哪{2}是往回数两步。所以HEAD{2}不是两次提交以前而是HEAD 移动了两次之前它指向哪儿。这两个说法在很多现场结果一样但含义不同——合并提交、切换分支、reset都算作 HEAD 的移动所以计数的口径要看动作不是看提交条数。官方还举了另一个形式的例子master{one.week.ago}表示本地仓库中 master 一周前指向的地方台账 G07。也就是说{...}里除了写步数还可以写时间。写法含义HEAD{0}HEAD 现在的位置HEAD{2}HEAD 两次移动之前所在的地方master{one.week.ago}本地仓库中 master 一周前指向的地方有了这层理解提交之后还能不能救的答案就具体了能救的前提是那条提交在 reflog 里还指得着。找到那个位置之后再按第五章的三档去决定要回到哪一层。6.3 边界要写实它只在本地reflog 有用但它的适用范围要说实不能夸大。第一它是本地的。官方定义里写得很清楚reflog 记录的是本地仓库中引用的更新台账 G07。它不跟着推送走别的机器上没有你这里的这份记录你也不能拿它去指挥别人的仓库。第二它记录的是引用的更新不是文件内容。它给你的是HEAD 曾经指向哪条提交这一层信息。至于那条提交里的文件长什么样你得回到那条提交去看。第三关于能留多久本文不写任何具体的天数也不写任何回收机制。能写的只有一句reflog 记录的是本地仓库里引用的更新它是否还够用取决于那些记录是不是还在。所以真要动手救请先只读地看一眼 reflog确认要回去的那个位置还在记录里再决定下一步不要凭记忆直接敲回退命令。本章可以带走的一句reflog 记录的是本地仓库里引用的更新HEAD{2}指的是HEAD 两次移动之前所在的地方它只在本地有效动手前先只读看一眼确认那个位置还在。七、顺序与底线7.1 先查表再动手把前面五章压成一张表看处境找网看代价。你现在的处境该用哪张网代价是什么文件改乱了还没add还原工作区工作区当前内容被覆盖源里没有的已跟踪路径会被移除已经add文件想留着只还原索引无内容损失改动退回工作区已经add文件也不要了工作区与索引一起还原工作区当前内容被覆盖提交已落下内容要留reset --soft不动文件与索引只移动分支顶端提交已落下索引也要清reset --mixed默认不动文件清空索引提交已落下工作树也要回到那条提交reset --hard必须先确认未跟踪文件覆盖工作树、移除不在目标提交中的已跟踪文件、可能覆盖未跟踪文件reset 做过之后想找回去先看 reflog再按上面的档位决定取决于记录是不是还在这张表里出现次数最多的一个字是先看不是先敲。这不是啰嗦前面几章的所有判断都建立在改动落在哪一层这个信息上而这个信息只能靠只读命令看出来的。7.2 底线三条第一条先看清再动手。git status、git diff、git reflog这几条只读命令成本是零信息是全的。任何时候只要你不确定改动落在哪一层就先跑它们不要先跑会改状态的命令。第二条--hard之前先确认未跟踪文件会不会被覆盖。官方明确说它可能覆盖未跟踪文件台账 G04。所以执行之前先用只读命令把未跟踪的文件列一遍工作区里有新加、还没进过任何提交的文件时先把它们复制出去再考虑执行。第三条重要改动先复制一份再试。这一条的适用范围比 Git 本身更宽在动手改任何不确定能不能恢复的东西之前先做一个可回退的副本。在本文范围内最直接的做法就是把整个目录复制出一份如果你是用虚拟机跑靶场也可以在动手前先记下一个能退回去的状态点出事就退回来。副本的妙处在于它不依赖你对 Git 的了解程度——哪怕你这一步判断错了退回副本就是。副本的价值不在于它多专业而在于它把不可逆变成了可逆。这三条按顺序执行其实覆盖了绝大多数改坏了的现场。真正容易出事的从来不是命令本身而是在没看清状态的情况下用了比现场需要更重的那一招。完整版环境对照表靶场环境怎么搭、改坏了怎么退前面这套先看清层次、再决定动手的顺序同样适用。这份对照表按平台整理了可行路径与推荐做法放在资料包里扫码即可获取本章可以带走的一句先看清再动手、--hard前先确认未跟踪文件、重要改动先复制一份——这三条底线比背下任何一条命令都值钱。附表 A本文引用事实与官方出处对照表事实出处本文位置git restore的 NAME 行为git-restore - Restore working tree files作用是用恢复源的内容还原工作树中指定的路径已跟踪但源中不存在的路径会被移除git-restoreNAME / DESCRIPTION台账 G01S7截至 2026-10-073.1、3.3git restore用--staged还原索引内容用--staged --worktree同时还原工作树与索引git-restoreDESCRIPTION台账 G024.1、4.3默认恢复源给了--staged就从HEAD还原否则从索引还原--source可从其他提交还原git-restoreDESCRIPTION台账 G033.2、4.1git reset的mode默认是--mixed--mixed保持工作目录不变、索引更新为与新HEAD一致、不会有东西已暂存--soft工作树文件与索引都不动--hard用commit覆盖所有文件与目录并可能覆盖未跟踪文件不在commit中的已跟踪文件会被移除索引更新以匹配新HEADgit-resetOPTIONS台账 G045.1、5.2、5.3、7.1、7.2--merge重置索引并更新工作树中有差异的文件、保留未暂存改动冲突时 reset 会被中止git-resetOPTIONS台账 G055.3执行 reset 之前ORIG_HEAD被设为当前分支的顶端git-resetDESCRIPTION台账 G065.3reflog 记录分支顶端与其他引用在本地仓库中被更新的时间HEAD{2}表示 HEAD 两次移动之前所在的地方master{one.week.ago}表示本地仓库中 master 一周前指向的地方git-reflogDESCRIPTION台账 G076.1、6.2、6.3git reflog show是默认子命令显示所给引用默认HEAD的日志reflog 覆盖所有近期动作HEAD reflog 还记录分支切换等同于git log -g --abbrev-commit --prettyonelinegit-reflogDESCRIPTION台账 G086.1文档版本锚点git-restore页标注 last updated in 2.55.0、git-status页标注 last updated in 2.53.0引用一律写截至 2026-10-07不写死为 Git 版本git-restore/git-status页脚台账 G09全篇日期口径附表 B术语速查表术语一句话解释工作区你能直接打开、编辑的当前文件版本最外、最容易被改坏的一层索引 / 暂存区下一次提交的候选清单git add的产物已提交写进本地仓库历史的改动以提交记录的形式存在还原restore用某个恢复源的内容覆盖指定路径靶子分工作区与索引两个回退reset把分支顶端移到另一个提交同时按模式决定是否动索引与工作树ORIG_HEADreset 之前 Git 替你记下的原来的位置reflog记录本地仓库中引用何时被更新的日志可按步数或时间往回指未跟踪文件没被git add过、也不在任何提交里的新文件--hard可能波及写在最后这篇用到的资料写这篇文章时我一直在想一件事靶场里改配置改坏了真正让人不敢再动手的往往不是缺命令而是不清楚改动落在哪一层。顺手也整理了几份配套的东西靶场环境对照表DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径Web 安全学习路线图从基础打牢到安全管理四个阶段各学什么常用靶场清单每个靶场练什么、适合哪个阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「靶场」优先通过。拿到之后建议先看环境对照表那一份把它和本文的先看清在哪一层、再决定动哪张网配着看改坏了不容易慌。