每个 commit 存储每个文件的完整快照和完整快照，或者存储该特定提交中的每个文件的完整快照。提交后，将永远无法更改。因此，您提交的所有旧提交都拥有所有文件的 all 版本。它们一直处于冻结状态，并且为了保持这种安全而不占用太多磁盘空间，它们采用特殊的压缩，只读，仅Git形式。

每个提交都有一个“真名”：原始哈希ID。运行git log时，您会看到这些庞大的丑陋ID，有时甚至是它们的精简版本。该原始哈希ID始终可以用来命名那个提交。其他名称（例如master或某些其他分支或标记名称）也可以命名一个特定的提交，但是 branch 名称会随着时间的推移而变化：分支名称只是保留了该哈希的哈希ID。 last 提交应被视为该分支的一部分。

由于提交中的文件是冻结的且仅支持Git，因此您需要一种方法来处理这些文件的未冻结版本和重构版本。 Git允许您使用自己的文件的方式是将冻结的，压缩的，仅Git的文件（我称为 freeze-dried ）复制到工作区，在该区域中，文件将恢复为正常状态格式。 Git将此工作区域称为工作树，或者有时称为工作树或工作目录或这些名称的某些变体。 （“工作目录”仅意味着一个文件夹级别，因此多年来，Git人士一直试图使其始终使用“工作树”这个词组。我有时会用连字符对其进行连字。）

您可以使用git checkout将所有文件从任何特定提交导入到工作树中。为此，您可以给git checkout提供历史提交的原始哈希ID。 ¹ 当然，问题在于，这会检查整个提交，删除这些文件的版本来自您正在处理的任何分支中的最后一次提交，然后将其替换为旧提交中的版本。

因此，就像在knittl's answer中一样，您可能只想从一个旧提交中提取一个一个（或几个）文件到您的工作树区域中，以便可以看到它并对其进行工作。 git show命令可以使用git show hash:path显示来自任何提交的一个文件。这会将文件的内容显示为git show的标准输出，因此您需要将该输出重定向到计算机上某个位置的新文件（可以在工作树内或外部的任何位置）。 / p>

执行此操作的另一种方法是创建第二个工作树。自从Git 2.5（通过Git 2.15在多个版本中修复了一些重要的重大错误）以来， ² Git有了git worktree命令。可以告诉此命令在当前工作树之外的某个地方创建一个 new 工作树。 Git以前每个存储库只有一个工作树。现在，Git可以拥有多个功能，我们必须将原始名称称为：我在这里使用“主要”或“主要”一词。

要使用git worktree add获得分离的HEAD 提交（再次参见脚注1），请运行git worktree add path commit-hash。例如，如果您想要 使用的所有文件的旧版本都在提交28014c1084中，并且/tmp/foo是放置它们的好地方，那么您可以运行：

$ git worktree add /tmp/foo 28014c1084

会打印出这样的内容（取决于Git的年份）：

Preparing worktree (detached HEAD 28014c1084)
HEAD is now at 28014c1084

这时，/tmp/foo中存在一个充满文件的新树，而这些文件是从提交28014c1084中提取的文件的 all 。

完成添加的工作树后-已经复制了您关心的所有文件，只需删除即可：

$ rm -r /tmp/foo

，然后使用git worktree prune从工作树列表中将其删除：

$ git worktree list
[path]    d9f6f3b619 [master]
/tmp/foo  28014c1084 (detached HEAD)
$ git worktree prune
$ git worktree list
[path]    d9f6f3b619 [master]

¹ 这将产生Git称为分离式HEAD 的内容。这对于查看历史提交非常有用，而对于进行新工作则不太好。要退出此模式，只需git checkout任何分支名称。

² 如果您的Git版本早于2.15，只要您不要离开添加的工作树就可以使用git worktree add周围太久了。最棘手的错误已在2.15中修复，该错误是在两周左右后，如果您在主工作树中工作了两个或两个以上星期，而又留下了一个添加的工作树，则添加的工作树的内部对象可能会被意外破坏。在某些情况下。因此，我建议使用Git 2.5到2.14的任何人的简单经验法则是：如果可能，请升级；否则，最多只能使用添加的工作树一周左右。

您可以使用git show在任何给定的提交中显示文件的内容：

git show deadbeef:path/to/file1 > file1.old