7.7 Git 工具 - Reset 详解

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

实际上，要查看这个快照的样子非常容易。下面是一个示例，展示了如何获取 HEAD 快照中每个文件的实际目录列表和 SHA-1 校验和。

Git 的 cat-file 和 ls-tree 命令是“管道”命令，用于较低级别的操作，在日常工作中并不常用，但它们有助于我们理解这里发生的事情。

索引是你**打算提交的下一个快照**。我们之前也把它称为 Git 的“暂存区”，因为当你运行 git commit 时，Git 查看的就是这里的内容。

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

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

技术上来说，索引并不是一个树结构——它实际上被实现为一个扁平的清单（manifest）——但对我们目前的理解来说，已经足够接近了。

最后，你拥有你的工作目录（也常被称为“工作树”）。另外两棵树将它们的内容以一种高效但不方便的方式存储在 .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 [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 选项，允许你逐个 hunks 地选择性地还原文件内容。