7.7 Git 工具 - 揭秘 Reset

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

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

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

索引 是你建议的下一次提交。我们也将这个概念称为 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 [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 选项，允许你逐个块地选择性地恢复文件内容。