我一直在阅读官方的 GIT 手册，我正在努力理解git restore命令，我相信它应该取代checkout的部分功能。无论如何，这就是我所处的位置：
- 我在工作目录中编辑一个名为 git.md 的文件
- 然后，我暂存该文件，但继续在我的工作区中对
git.md文件进行修改。我决定要恢复到暂存区域中的文件。 - 我使用该
git restore git.md，它将当前git.md替换为暂存区域中的快照。
按预期工作。下一个场景：
- 我对 git.md 进行了一些更改并暂存它，但意识到我想在上次提交中将其替换为
git.md文件的快照。 - 我跑
git restore --staged git.md - 我检查了文件，我对文件所做的所有更改仍然存在，并且当前位于工作区中。
我期待看到暂存的 git.md 替换为上次提交的git.md的快照。
问题，这是它应该的工作方式，还是应该用上次提交中的分阶段git.md替换
git restore 手册页的介绍部分内容如下：
使用还原源中的某些内容恢复工作树中的指定路径.
...
该命令还可用于使用 --staged 恢复索引中的内容，或使用 --staged --worktree 恢复工作树和索引。
因此，--staged参数将命令的目标仅指定为暂存区域(索引)。
要还原的文件的源由--source参数指定，但根据目标具有不同的默认值：
如果未指定，则在给定 --staged 时从 HEAD 还原内容，否则从索引还原内容。
因此，两个常见的选项是：
--staged或--source均未指定，从暂存区域恢复工作副本。实际上，它"撤消"了任何尚未上演的本地更改。--staged指定但未--source，从 HEAD(当前签出的提交)恢复暂存区域。实际上，它"取消"了任何尚未提交的更改。
要从当前提交恢复暂存区域和工作树，必须同时指定--staged和--worktree，并显式声明源。
手册给出了这个例子：
git restore --source=HEAD --staged --worktree hello.c
而这个相当神秘的缩写形式：
git restore -s@ -SW hello.c
据我了解，这相当于一个接一个地运行两个默认模式：
git restore --staged # target staging area, implicit source HEAD
git restore # implicit target worktree, implicit source staging area
最后一点，我看到手册指出此命令仍然是"实验性的"。将来可能会对其进行调整，并且这种情况将变得更容易(或只是不同)。