7.7 Git 工具 - Reset 深度解析

HEAD 是指向当前分支引用的指针，该引用又是指向该分支上最后一次提交的指针。这意味着 HEAD 将是创建的下一个提交的父节点。通常最简单的理解方式是，HEAD 是**您在该分支上的最后一次提交的快照**。

实际上，查看该快照的样子相当容易。这里有一个获取 HEAD 快照中每个文件的实际目录列表和 SHA-1 校验和的示例

Git 的 cat-file 和 ls-tree 命令是用于低层操作的“管道（plumbing）”命令，在日常工作中并不常用，但它们帮助我们理解这里发生了什么。

_索引_是您**建议的下一个提交**。我们也一直将这个概念称为 Git 的“暂存区”，因为当您运行 git commit 时，Git 会查看这里。

Git 会用一份包含所有上次检出到您工作目录中的文件内容及其原始状态的列表来填充此索引。然后，您将其中一些文件替换为新版本，git commit 会将其转换为新提交的树。

同样，这里我们使用 git ls-files，它更多是一个幕后命令，显示您的索引当前是什么样子。

索引在技术上不是一个树形结构——它实际上是作为扁平清单实现的——但为了我们的目的，这已经足够接近了。

最后，您拥有自己的_工作目录_（也常被称为“工作树”）。其他两棵树以高效但不方便的方式将其内容存储在 .git 文件夹中。工作目录将它们解包成实际文件，使您更容易编辑它们。将工作目录视为一个**沙盒**，您可以在提交到暂存区（索引）然后提交到历史记录之前，在此处尝试更改。

reset 要做的第一件事是移动 HEAD 所指向的位置。这与更改 HEAD 本身不同（checkout 就是这样做的）；reset 移动 HEAD 所指向的分支。这意味着如果 HEAD 设置为 master 分支（即您当前在 master 分支上），运行 git reset 9e5e6a4 将首先使 master 指向 9e5e6a4。

无论您调用哪种带提交的 reset 形式，这都是它始终尝试做的第一件事。使用 reset --soft，它将只停在那里。

现在花点时间看看这张图，并理解发生了什么：它本质上撤销了上一个 git commit 命令。当您运行 git commit 时，Git 会创建一个新提交并将 HEAD 所指向的分支移动到它上面。当您 reset 回到 HEAD~（HEAD 的父节点）时，您是在将分支移回其原始位置，而不更改索引或工作目录。您现在可以更新索引并再次运行 git commit，以完成 git commit --amend 所做的事情（参见修改最后一次提交）。

请注意，如果您现在运行 git status，您将看到索引与新 HEAD 之间的差异以绿色显示。

reset 将要做的下一件事是使用 HEAD 当前指向的快照内容更新索引。

如果您指定 --mixed 选项，reset 将在此点停止。这也是默认行为，所以如果您根本不指定任何选项（在这种情况下只使用 git reset HEAD~），命令将在此处停止。

现在再花点时间看看这张图，并理解发生了什么：它仍然撤销了您的最后一次 commit，但同时也_取消暂存_了所有内容。您回滚到了运行所有 git add 和 git commit 命令之前的状态。

reset 将做的第三件事是使工作目录看起来像索引。如果您使用 --hard 选项，它将继续到这个阶段。

所以让我们思考一下刚才发生了什么。您撤销了上次提交，git add 和 git commit 命令，**以及**您在工作目录中完成的所有工作。

重要的是要注意，这个标志（--hard）是使 reset 命令变得危险的唯一方式，也是 Git 实际上会销毁数据的极少数情况之一。任何其他 reset 调用都可以很容易地撤销，但 --hard 选项不能，因为它会强制覆盖工作目录中的文件。在这个特定情况下，我们仍然在 Git 数据库中的一个提交中拥有文件 **v3** 版本，我们可以通过查看 reflog 来找回它，但如果我们没有提交它，Git 仍然会覆盖该文件，并且它将无法恢复。

reset 命令以特定顺序覆盖这三棵树，并在您指示时停止

运行 git checkout [branch] 与运行 git reset --hard [branch] 非常相似，因为它会更新所有三棵树以使其看起来像 [branch]，但有两点重要区别。

首先，与 reset --hard 不同，checkout 是工作目录安全的；它会检查以确保不会覆盖已更改的文件。实际上，它比这更智能一些——它尝试在工作目录中进行一次简单的合并，因此您_未_更改的所有文件都将被更新。而 reset --hard 则会不经检查地全面替换所有内容。

第二个重要区别是 checkout 如何更新 HEAD。reset 会移动 HEAD 所指向的分支，而 checkout 则会移动 HEAD 本身以指向另一个分支。

例如，假设我们有 master 和 develop 分支，它们指向不同的提交，并且我们当前在 develop 上（因此 HEAD 指向它）。如果我们运行 git reset master，那么 develop 本身现在将指向与 master 相同的提交。如果我们改为运行 git checkout master，则 develop 不会移动，而是 HEAD 本身移动。HEAD 现在将指向 master。

所以，在两种情况下，我们都将 HEAD 移动到指向提交 A，但_如何_这样做却大相径庭。reset 将移动 HEAD 指向的分支，checkout 移动 HEAD 本身。

另一种运行 checkout 的方式是带文件路径，它和 reset 一样，不会移动 HEAD。它就像 git reset [branch] file 一样，更新索引中该提交处的该文件，但它也会覆盖工作目录中的文件。它会完全像 git reset --hard [branch] file（如果 reset 允许您运行该命令）——它不是工作目录安全的，并且不移动 HEAD。

此外，与 git reset 和 git add 一样，checkout 也将接受 --patch 选项，允许您逐个 hunk 地选择性地恢复文件内容。