7.7 Git 工具 - 重置揭秘

HEAD 是当前分支引用的指针，而该引用又指向该分支上的最后一次提交。这意味着 HEAD 将是下一次创建提交的父节点。通常，将 HEAD 看作是你所在分支上最后一次提交的快照是最简单的。

事实上，查看该快照的样子非常容易。以下是一个获取 HEAD 快照中每个文件的目录列表和 SHA-1 校验和的示例。

Git 的 cat-file 和 ls-tree 命令是用于底层操作的“管道”命令，平时工作中很少直接用到，但它们能帮助我们理解幕后发生了什么。

索引是你预期的下一次提交。我们之前也将其称为 Git 的“暂存区”（Staging Area），因为当你运行 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 选项不行，因为它会强制覆盖工作目录中的文件。在此特定场景下，我们的 v3 版本文件依然存在于 Git 数据库的一个提交中，我们可以通过查看 reflog 来找回它。但如果我们还没有提交它，Git 就会直接覆盖文件，且无法找回。

reset 命令按特定顺序覆盖这三棵树，并在你指定的阶段停止：

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

首先，与 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 [分支] 文件 类似，即用该提交中的该文件更新索引，但它也会覆盖工作目录中的文件。这完全等同于 git reset --hard [分支] 文件（如果 reset 允许你这样执行的话）——它不是工作目录安全的，并且不会移动 HEAD。

此外，和 git reset 以及 git add 一样，checkout 也接受 --patch 选项，允许你逐块有选择地恢复文件内容。