git reset

我们要研究的第一棵树是“工作目录”。该树与本地文件系统同步，代表对文件和目录中的内容所做的即时更改。

在我们的演示存储库中，我们对 reset_lifecycle_file 进行了修改并添加了一些内容。调用 git status 表明 Git 知道文件的更改。这些更改目前是第一棵树“工作目录”的一部分。Git status 可用于显示对工作目录的更改。它们将以红色显示，带有“已修改”前缀。

接下来是“暂存索引”树。这棵树正在跟踪工作目录更改，这些更改已通过 git add 提升，以便存储在下一次提交中。这棵树是一种复杂的内部缓存机制。Git 通常会尝试向用户隐藏暂存索引的实现细节。

要准确查看暂存索引的状态，我们必须使用鲜为人知的 Git 命令 git ls-files。git ls-files 命令本质上是一个用于检查暂存索引树状态的调试实用程序。

这里我们使用 -s 或 --stage 选项执行了 git ls-files。如果没有 -s 选项，git ls-files 输出只是一个文件名和路径列表，这些文件名和路径目前是索引的一部分。-s 选项显示暂存索引中文件的其他元数据。此元数据是暂存内容的模式位、对象名称和阶段号。这里我们关注的是对象名称，即第二个值 (d7d77c1b04b5edd5acfc85de0b592449e5303770)。这是一个标准的 Git 对象 SHA-1 哈希。它是文件内容的哈希。提交历史记录存储自己的对象 SHA，用于识别指向提交和引用的指针，而暂存索引有自己的对象 SHA，用于跟踪索引中文件的版本。

接下来，我们将把修改后的 reset_lifecycle_file 提升到暂存索引中。

这里我们调用了 git add reset_lifecycle_file，它将文件添加到暂存索引中。调用 git status 现在在“要提交的更改”下以绿色显示 reset_lifecycle_file。需要注意的是，git status 不是暂存索引的真实表现。git status 命令输出显示提交历史记录和暂存索引之间的变更。现在我们来看看暂存索引的内容。

我们可以看到，reset_lifecycle_file 的对象 SHA 已从 e69de29bb2d1d6434b29ae775ad8c2e48c5391 更新为 d7d77c1b04b5acfc85de0b592449e530370。

最后一棵树是提交历史记录。git commit 命令将更改添加到提交历史记录中的永久快照中。此快照还包括提交时暂存索引的状态。

这里，我们创建了一个新的提交，其中包含 "update content of resetlifecyclefile"。变更集已添加到提交历史记录中。此时调用 git status 表明任何树都没有待处理的更改。执行 git log 将显示提交历史记录。现在我们已经通过三棵树跟踪了这个变更集，我们可以开始使用 git reset 了。

此示例演示了 main 分支上的一系列提交。HEAD 引用和 main 分支引用当前指向提交 d。现在我们来执行并比较 git checkout b 和 git reset b。

使用 git checkout 时，main 引用仍然指向 d。HEAD 引用已被移动，现在指向提交 b。该代码存储库现在处于“游离的 HEAD”状态。

相比之下，git reset 会将 HEAD 和分支引用都移到指定的提交中。

除了更新提交引用指针外，git reset 还将修改三棵树的状态。引用指针修改总是会发生，是对第三棵树提交树的更新。命令行参数 --soft、--mixed 和 --hard 指导如何修改暂存索引和工作目录树。

这是最直接、最危险和最常用的选项。传递 --hard 时，提交历史记录引用指针将更新为指定的提交。然后，将重置暂存索引和工作目录以匹配指定提交的暂存索引和工作目录。暂存索引和工作目录任何先前待处理的更改都将被重置以匹配提交树的状态。这意味着在暂存索引和工作目录中挂起的所有待处理工作都将丢失。

为了演示这一点，我们继续使用之前建立的三棵树示例代码存储库。首先，我们对代码存储库进行一些修改。在示例代码存储库中执行以下命令：

这些命令创建了一个名为 new_file 的新文件并将其添加到代码存储库中。此外，reset_lifecycle_file 的内容将被修改。有了这些更改，现在我们使用 git status 来检查代码存储库的状态。

这里我们调用了 git add reset_lifecycle_file，它将文件添加到暂存索引中。调用 git status 现在在“要提交的更改”下以绿色显示 reset_lifecycle_file。需要注意的是，git status 不是暂存索引的真实表现。git status 命令输出显示提交历史记录和暂存索引之间的变更。现在我们来看看暂存索引的内容。

我们可以看到 new_file 已添加到索引中。我们已经对 reset_lifecycle_file 进行了更新，但暂存索引 SHA (d7d77c1b04b5edd5acfc85de0b592449e5303770) 保持不变。这是预期的行为，因为尚未使用 git add 将这些更改提升到暂存索引中。这些更改位于工作目录中。

现在，我们来执行 git reset --hard 并检查存储库的当前状态。

这里我们使用 --hard 选项执行了“硬重置”。Git 显示的输出表明 HEAD 指向最新提交 dc67808。接下来，我们使用 git status 检查存储库的状态。Git 表示没有待处理的更改。我们还检查了暂存索引的状态，发现它已被重置到添加 new_file 之前的某个点。我们对 reset_lifecycle_file 的修改和添加的 new_file 已被销毁。这种数据丢失无法撤销，这一点需要注意。

这是默认的操作模式。引用指针已更新。暂存索引重置为指定提交状态。从暂存索引中撤销的所有更改都将移至工作目录。我们继续。

在上面的示例中，我们对存储库进行了一些修改。同样，我们添加了一个 new_file 并修改了 reset_lifecycle_file 的内容。然后，使用 git add 将这些更改应用于暂存索引。当代码存储库处于这种状态时，我们现在将执行重置。

这里我们执行了“混合重置”。重申一下，--mixed 是默认模式，其效果与执行 git reset 的效果相同。通过检查 git status 和 git ls-files 的输出，可以看出，暂存索引已被重置为索引中唯一文件为 reset_lifecycle_file 的状态。reset_lifecycle_file 的对象 SHA 已重置为以前的版本。

这里需要注意的重要事项是，git status 向我们展示了对 reset_lifecycle_file 的修改，并且有一个未跟踪的文件 new_file。这是显式的 --mixed 行为。暂存索引已重置，待处理更改已移至工作目录。将此与 --hard 重置案例进行比较，在这种情况下，暂存索引被重置，工作目录也被重置，从而丢失了这些更新。

传递 --soft 参数时，ref 指针会更新，重置就此停止。暂存索引和工作目录保持不变。这种行为可能很难清楚地展示出来。我们继续我们的演示代码存储库，为软重置做好准备。

在这里，我们再次使用 git add 将修改后的 reset_lifecycle_file 提升到暂存索引中。我们确认索引已使用 git ls-files 输出进行了更新。git status 的输出现在以绿色显示“要提交的更改”。我们之前示例中的 new_file 作为未跟踪文件浮动在工作目录中。我们快速执行 rm new_file 来删除文件，因为在接下来的示例中我们不需要它。

当存储库处于这种状态时，我们现在执行软重置。

我们已经执行了“软重置”。使用 git status 和 git ls-files 检查代码存储库状态显示没有任何更改。这是预期的行为。软重置只会重置提交历史记录。默认情况下，使用 HEAD 作为目标提交调用 git reset。既然我们的提交历史记录已经在 HEAD 上了，并且我们隐式重置为 HEAD，所以实际上什么也没发生。

为了更好地理解和利用 --soft，我们需要一个不是 HEAD 的目标提交。我们在暂存索引中有 reset_lifecycle_file 在等待。我们来创建一个新提交。

此时，我们的代码存储库应该有三次提交。我们将回到第一次提交。为此，我们需要第一次提交的 ID。这可以通过查看 git log 的输出找到。

请记住，提交历史记录 ID 对于每个系统都是唯一的。这意味着本示例中的提交 ID 将与您在个人计算机上看到的不同。在本例中，我们关注的提交 ID 是 780411da3b47117270c0e3a8d5dcfd11d04a4。这是与“初始提交”相对应的 ID。找到此 ID 后，我们将使用它作为软重置的目标。

回到过去之前，我们先检查一下代码存储库的当前状态。

这里我们执行 git status 和 git ls-files -s 的组合命令，这表明暂存索引中的代码存储库和 reset_lifecycle_file 的版本为 67cc52710639e5da6b515416fd779d0741e3762e。考虑到这一点，我们执行软重置回第一次提交。

上面的代码执行“软重置”，还调用 git status 和 git ls-files 组合命令，输出存储库的状态。我们可以检查代码存储库状态的输出并记下一些有趣的观察结果。首先，git status 表示对 reset_lifecycle_file 进行了修改，并重点显示了这些修改，表示它们是为下次提交而暂存的变更。其次，git ls-files 输出表明暂存索引没有变更，保留了我们之前使用的 SHA 67cc52710639e5da6b515416fd779d0741e3762e。

为了进一步阐明此次重置中发生了什么，我们看一下 git log：

现在，日志输出显示提交历史记录中只有一次提交。这有助于清楚地说明 --soft 做了什么。与所有 git reset 调用一样，重置采取的第一个操作是重置提交树。我们之前使用 --hard 和 --mixed 的例子都违背了 HEAD，也没有让提交树回到过去。这就是软重置期间的所有情况。

这可能会让人困惑为什么 git status 显示有修改过的文件。--soft 不触及暂存索引，因此我们暂存索引的更新会跟随我们在提交历史记录中回到过去。这可以通过 git ls-files-s 的输出来证实，该输出显示 reset_lifecycle_file 的 SHA 保持不变。提醒一下，git status 不显示“三棵树”的状态，它本质上显示了它们之间的差异。在这种情况下，它显示暂存索引领先于提交历史记录中的更改，就好像我们已经暂存了它们一样。

只要您在重置后添加新提交，Git 就会认为您的本地历史记录与 origin/main 有所不同，同步存储库所需的合并提交可能会让您的团队感到困惑和沮丧。

关键是，确保您要在出错的本地实验中使用 git reset ，而不是在已发布的变更上使用。如果您需要修复公共提交，git revert 命令是专门为此目的而设计的。

从暂存区移除指定文件，但保持工作目录不变。这会在不覆盖任何更改的情况下取消暂存文件。

重置暂存区以匹配最近的提交，但保持工作目录不变。这会在不覆盖任何更改的情况下取消暂存所有文件，从而使您有机会从头开始重新构建暂存的快照。

重置暂存区和工作目录以匹配最近的提交。除了取消暂存更改外，--hard 标记还告诉 Git 覆盖工作目录中的所有更改。换句话说：这会抹去所有未提交的更改，因此在使用之前，请确保您真的想丢弃本地开发项目。

将当前分支提示向后移动到 commit，将暂存区域重置为匹配，但不更改工作目录。＜commit＞ 后所做的所有变更都将保存在工作目录中，这样您可以使用更简洁、更具原子性的快照重新提交项目历史记录。

将当前分支提示向后移动到 ，并将暂存区域和工作目录均重置为匹配。这不仅会删除未提交的变更，还会删除之后的所有提交。

准备暂存快照时经常会遇到 git reset 命令。下个示例假设您已经将两个名为 hello.py 和 main.py 的文件添加到存储库中。

如您所见，git reset 允许您取消暂存与下一次提交无关的更改，从而帮助您保持高度集中的提交。

下个示例显示了一个更高级的用例。它演示了当您做一个新实验已有一段时间，但在提交了几张快照后决定将其完全丢弃时会发生什么。

git reset HEAD~2 命令将当前分支向后移动两次提交，实际上从项目历史记录中删除了我们刚刚创建的两个快照。请记住，这种重置只能用于未发布的提交。如果您已经将提交推送到共享存储库，则切勿执行上述操作。

回顾一下，git reset 是一个强大的命令，用于撤销对 Git 代码存储库状态的本地变更。git reset在“Git 的三棵树”上运行。这些树分别是提交历史记录 (HEAD)、暂存索引和工作目录。有三个命令行选项分别对应于这三棵树。选项 --soft、--mixed 和 --hard 可以传递给 git reset。

在本文中，我们利用了其他几个 Git 命令来帮助演示重置流程。如需详细了解这些命令，请访问这些命令各自的页面：git status、git log、git add、git checkout、git reflog 和 git revert。