企业官网建设流程全解析

授权与合规声明
本文全部操作对象均为自建隔离靶场（本机容器或隔离虚拟机），涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款，须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离，不含任何攻击步骤、利用载荷与绕过手法，请勿将文中环境指向任何非自有系统。

一、场景与结论先行

1.1 三个很常见的现场

在靶场里跟着教程改配置，几乎每个初学者都会撞上同一堵墙：手比脑子快，改完才发现不对劲。

第一种现场，文件改乱了，想让它回到刚才的样子。教程让你改一处配置，你顺手多改了几行，回头再读原文，已经记不清原本写的是什么。

第二种现场，已经git add了，突然发现加错了。改动本身没错，是你不该把这几个文件纳入这一次提交。

第三种现场，提交已经落下，才发现这一提交不该要。可能是把测试用的临时改动一起提交了，也可能是那几行调完忘了删。

三种现场看起来都叫"改坏了"，但它们坏在不同的层，能用的补救手段也完全不同。混为一谈的常见后果是：本来一条只还原工作区的命令就能解决的事，你却用了更重的那一招，把本来还想留着的东西一起抹掉了。

1.2 先问自己三句话

在敲任何一条命令之前，先停下来，回答三句话：

1. 我改的是什么？是一个文件、一组文件，还是整个目录？
2. 改动落在哪一层？只在工作区里，还是已经进了索引？
3. 提交了没有？是还没提交，还是提交已经落下了？

这三句问完，"该用哪张网"基本就定了。本文先把答案放在下面这张表里，后面几章再逐个展开。

1.3 本文覆盖什么，明确不覆盖什么

先说清边界：本文只覆盖工作区、索引、本地提交这三层。这三层都在你自己的机器上，动作的后果也只落在你自己的机器上，所以它属于"环境可恢复性"这件事，而不是 Git 的全套教程。

不覆盖的部分同样要说清：分支策略不写，协作流程不写，远端仓库不写。涉及多人、涉及推送、涉及远程分支的操作，代价和判断与本地完全不同，不该和"本地改坏了"混在一起讲。本文也不展开任何与抓取、请求构造相关的内容，所有操作对象都是自建隔离靶场里的本地代码。

本章可以带走的一句：先分清"改了什么、改到哪一层、提交了没有"，再决定用哪张网——顺序错了，救得越狠、丢得越多。

二、先看清三种状态

2.1 只读三连：status 与 diff

改坏之后最危险的动作，是凭记忆立刻敲一条会改变状态的命令。更稳的做法是先用只读命令把现状看清楚。

⚠️代码待验证

gitstatus

git status回答的是"改动落在哪一层"：哪些改动已经进了索引（准备被提交），哪些还只在工作区。

⚠️代码待验证

gitdiffgitdiff--staged

git diff看的是工作区与索引之间的差异，也就是"改了但还没add"的那部分；git diff --staged看的是索引与HEAD之间的差异，也就是"已经add、即将进入下一次提交"的那部分。另外还有git status --short，用短格式把同一件事列得更紧凑。

这几条命令的共同点是只读，不改变任何状态。之所以反复强调这一点：它们是你判断"该用哪张网"的唯一依据。看不清就动手，等于闭着眼睛拆线。

2.2 三张网的靶子：工作区、索引、已提交

要把三张网用对，得先知道它们各自的靶子是什么。

• 工作区：你眼下能直接打开、编辑的那份文件。它是最外、最容易被改坏的一层。
• 索引：也叫暂存区。它是你为"下一次提交"准备的候选清单。git add做的事情，就是把工作区的某个改动放进索引。
• 已提交：提交落下之后，改动就写进了本地仓库的历史。这一层的"改动"不再是文件内容，而是一条一条的提交记录。

一层比一层深，一层比一层难改，但同时也一层比一层"有据可查"。工作区里的改动，一旦被覆盖就没了；索引里的内容，HEAD里通常还有一份；而提交，即使被回退，reflog 里往往还留着痕迹（见第六章）。

换个说法：这三张网并不是三个并列的工具，而是三个深度不同的入口。你在哪一层动手，就决定了另外两层受不受影响。所谓"判断该用哪张网"，本质上就是判断"这一次我希望影响几层"。想清楚这一点，再看命令的选项，选项就不再是一堆记不住的开关，而是一句句"我要动到这一层为止"的声明。

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--source=HEAD -- path/to/file

这里--source后面给哪个提交，由你按现场决定；写HEAD只是"从最近一次提交取"这个最常见的用法。

3.3 一个必须知道的后果：路径可能被移除

还有一条后果，很多人第一次遇到会吓一跳。官方原文说得很明确：若某路径已被跟踪、但在恢复源里不存在，它会被移除以与恢复源一致（台账 G01）。

把这句话翻译成现场：如果这个文件是你新加的、并且已经进了索引，而你要还原的那个源里根本没有它，那么还原之后，这个文件会从工作区消失。它不是被改回旧内容，而是被直接拿掉了。

所以还原工作区之前，先回答一个问题：我要还原的源里，到底有没有这个路径？如果这个文件是你刚建的、还没来得及提交，那么它很可能不在源里，还原就等于删掉它。真要在这种时候动手，先把它复制一份出去再说。

本章可以带走的一句：git restore默认从索引还原、给了--staged才从HEAD还原；源里没有的已跟踪路径会被移除，动手前先确认它在不在源里。

四、第二张网：还原索引

4.1--staged动的是哪一层

第一张网管的是工作区，第二张网管的是索引。同一族命令，靠--staged这个开关切换靶子。

官方说明：该命令也可用于用--staged还原索引中的内容（台账 G02）。结合上一章的默认规则（台账 G03），git 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 三档放在一起看

把三档并排摆开，差别就清楚了。

还有两种模式值得提一句。--merge的行为是：重置索引，并更新工作树中"在<commit>与 HEAD 之间有差异"的文件，但保留索引与工作树之间的未暂存改动；若某文件在<commit>与索引之间不同、且存在未暂存改动，reset 会被中止（台账 G05）。本文只用这一条已核口径，不展开其他模式。

最后一条与"反悔"直接相关：执行 reset 之前，ORIG_HEAD被设为当前分支的顶端（台账 G06）。也就是说，在 reset 动作发生之前，Git 先替你记下了一个"原来的位置"。这条记下来有什么用，第六章接着讲。

完整版环境对照表：靶场里改配置改出问题，只是时间早晚的事。这份对照表按平台列了靶场环境的可行路径与推荐做法，配合本文"回到已知状态"这条思路一起用更顺手。放在资料包里，扫码即可获取：

本章可以带走的一句：--soft只移动分支顶端、--mixed（默认）额外清空索引、--hard连工作树一起覆盖且可能波及未跟踪文件——三档代价差得很远，选之前先想清楚要动到哪一层。

六、提交之后还能不能救：reflog

6.1 reflog 记录的是什么

前面三张网都假设"改动还没走远"。那如果提交已经落下，甚至 reset 也已经执行过，还能不能救？这就轮到引用日志出场了。

官方的定义是：参考日志（reflogs）记录分支顶端与其他引用在本地仓库中被更新的时间（台账 G07）。注意这句话里的两个限定词：分支顶端与其他引用、本地仓库。reflog 记的是"引用什么时候动过"，而不是"文件内容怎么变过"。

git reflog show是默认子命令，显示所给引用（默认HEAD）的日志（台账 G08）。官方还说明，reflog覆盖所有近期动作，此外HEAD reflog 还记录分支切换（台账 G08）。它本质上是一个别名：git reflog show等价于git log -g --abbrev-commit --pretty=oneline（台账 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）。也就是说，@{...}里除了写步数，还可以写时间。

有了这层理解，"提交之后还能不能救"的答案就具体了：能救的前提，是那条提交在 reflog 里还指得着。找到那个位置之后，再按第五章的三档去决定要回到哪一层。

6.3 边界要写实：它只在本地

reflog 有用，但它的适用范围要说实，不能夸大。

第一，它是本地的。官方定义里写得很清楚：reflog 记录的是本地仓库中引用的更新（台账 G07）。它不跟着推送走，别的机器上没有你这里的这份记录，你也不能拿它去指挥别人的仓库。

第二，它记录的是引用的更新，不是文件内容。它给你的是"HEAD 曾经指向哪条提交"这一层信息。至于那条提交里的文件长什么样，你得回到那条提交去看。

第三，关于"能留多久"，本文不写任何具体的天数，也不写任何回收机制。能写的只有一句：reflog 记录的是本地仓库里引用的更新，它是否还够用，取决于那些记录是不是还在。所以真要动手救，请先只读地看一眼 reflog，确认要回去的那个位置还在记录里，再决定下一步；不要凭记忆直接敲回退命令。

本章可以带走的一句：reflog 记录的是本地仓库里引用的更新，HEAD@{2}指的是"HEAD 两次移动之前所在的地方"；它只在本地有效，动手前先只读看一眼，确认那个位置还在。

七、顺序与底线

7.1 先查表，再动手

把前面五章压成一张表：看处境，找网，看代价。

这张表里出现次数最多的一个字是"先看"，不是"先敲"。这不是啰嗦：前面几章的所有判断，都建立在"改动落在哪一层"这个信息上，而这个信息只能靠只读命令看出来的。

7.2 底线三条

第一条：先看清再动手。git status、git diff、git reflog这几条只读命令，成本是零，信息是全的。任何时候，只要你不确定改动落在哪一层，就先跑它们，不要先跑会改状态的命令。

第二条：--hard之前先确认未跟踪文件会不会被覆盖。官方明确说它可能覆盖未跟踪文件（台账 G04）。所以执行之前，先用只读命令把未跟踪的文件列一遍；工作区里有新加、还没进过任何提交的文件时，先把它们复制出去，再考虑执行。

第三条：重要改动先复制一份再试。这一条的适用范围比 Git 本身更宽：在动手改任何"不确定能不能恢复"的东西之前，先做一个可回退的副本。在本文范围内，最直接的做法就是把整个目录复制出一份；如果你是用虚拟机跑靶场，也可以在动手前先记下一个能退回去的状态点，出事就退回来。副本的妙处在于，它不依赖你对 Git 的了解程度——哪怕你这一步判断错了，退回副本就是。副本的价值不在于它多专业，而在于它把"不可逆"变成了"可逆"。

这三条按顺序执行，其实覆盖了绝大多数"改坏了"的现场。真正容易出事的，从来不是命令本身，而是在没看清状态的情况下，用了比现场需要更重的那一招。

完整版环境对照表：靶场环境怎么搭、改坏了怎么退，前面这套"先看清层次、再决定动手"的顺序同样适用。这份对照表按平台整理了可行路径与推荐做法，放在资料包里，扫码即可获取：

本章可以带走的一句：先看清再动手、--hard前先确认未跟踪文件、重要改动先复制一份——这三条底线比背下任何一条命令都值钱。

附表 A：本文引用事实与官方出处对照表

附表 B：术语速查表

写在最后：这篇用到的资料

写这篇文章时，我一直在想一件事：靶场里改配置改坏了，真正让人不敢再动手的，往往不是缺命令，而是不清楚改动落在哪一层。顺手也整理了几份配套的东西：

• 靶场环境对照表：DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径
• Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
• 常用靶场清单：每个靶场练什么、适合哪个阶段

资料是我自己整理的，放在下面这个码上，扫码即可获取：

添加时备注「靶场」，优先通过。

拿到之后建议先看环境对照表那一份，把它和本文的"先看清在哪一层、再决定动哪张网"配着看，改坏了不容易慌。