7.7 Git 工具 - 重识重置

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

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

Git 的 cat-file 和 ls-tree 命令是“底层”命令，用于更低级的操作，在日常工作中很少使用，但它们有助于我们了解这里发生了什么。

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