7.7 Git 工具 - Reset 命令解密

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

事实上，很容易看到快照是什么样子的。这里有一个例子，获取 HEAD 快照中每个文件的实际目录列表和 SHA-1 校验和

Git 的 cat-file 和 ls-tree 命令是 “底层（plumbing）” 命令，用于较低级别的操作，日常工作中并不常用，但它们可以帮助我们了解背后发生的事情。

索引（index） 是你的提议的下一个提交。我们也一直将这个概念称为 Git 的“暂存区（Staging Area）”，因为这是你运行 git commit 时 Git 查看的内容。

Git 使用上次检出到你的工作目录中的所有文件内容以及它们最初被检出时的样子来填充这个索引。 然后，你用它们的新版本替换其中一些文件，git commit 将其转换为新提交的树。

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

从技术上讲，索引不是树结构，它实际上是以扁平化的清单实现的，但就我们的目的而言，它已经足够接近了。

最后，你有你的工作目录（working directory）（通常也称为“工作树（working tree）”）。 其他两棵树将其内容以高效但不方便的方式存储在 .git 文件夹中。 工作目录将它们解压成实际文件，这使得你更容易编辑它们。 将工作目录视为一个沙箱（sandbox），你可以在将更改提交到暂存区（索引）然后再提交到历史记录之前尝试更改。

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，但也取消暂存（unstaged）了所有内容。 你回滚到你运行所有 git add 和 git commit 命令之前。

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

所以让我们考虑一下刚刚发生了什么。 你撤消了你的最后一个提交、git add 和 git commit 命令，以及你在工作目录中所做的所有工作。

重要的是要注意，此标志 (--hard) 是使 reset 命令危险的唯一方法，也是 Git 实际上会破坏数据的极少数情况之一。 任何其他 reset 调用都可以很容易地撤消，但 --hard 选项不能，因为它会强制覆盖工作目录中的文件。 在这种特殊情况下，我们仍然在 Git DB 的提交中保留了文件的 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 选项，以允许你选择性地逐块地还原文件内容。