>我错误地提交并将大型临时文件推送到 git 服务器。在 git 服务器上，我使用通过 Google 搜索找到的命令及其 Web 界面还原了最后一次提交，提交次数减少了 1，最后一次提交就消失了。
不过，服务器上的数据大小似乎并没有减少。我确实运行了那些"修剪"和"reflog"命令。在服务器上，有一个大的"包"文件和一个"idx"文件。我跑git verify-pack -v <file name>.idx，显示了很多数据，但每一行都像
[哈希代码] 斑点 [数字] [数字] [数字]
所以，我不知道它们是什么。我能否看到像"program.cs"这样的原始文件名，以便我可以看到临时文件是否仍然存在于存储库中？
要回答实际问题：对象没有文件名。 它们只是对象。
提交存储文件，但它们是间接的。 每个提交对象只有一个对一个树对象的引用。 在 Git 中，树对象由一系列记录组成，每条记录包含：
-
一个模式，它是表示八进制数的文本字符串，例如
100755、100644、40000等; - 路径名组件：不同长度的二进制(但通常有效的 UTF-8)字符串，不包含
/或 NUL 字节，后跟一个 NUL 字节;和 - 哈希 ID(二进制，长度为 20 字节)。
40000mode表示记录中的哈希 ID 是另一个树对象的哈希 ID，因此哈希 ID 必须是另一个树对象的哈希(否则存储库已损坏)。 其他模式意味着其他哈希 ID 用途，在这种情况下，哈希 ID 通常是 Blob 的哈希 ID。 还有另一种特殊情况：模式160000表示一个gitlink，并指示该条目提供子模块中预期和git checkout的哈希 ID。
因此，Blob IDB可以表示多个不同的文件路径名。 这些文件名是通过将每个树对象中的路径名段与导致查找最终对象的一系列对象中的最终模式(100755或模式)100644blob 对象连接起来来构造的。
也就是说，假设提交Ca的顶级树哈希 ID T1通过名称d1引用树T2，然后T2通过名称f1引用 blobBh。 然后 blobBh在此提交中表示文件d1/f1。 但是假设提交Cb有树 T3，它通过名称d2引用树 T 4，而T4通过名称f2引用Bh。 然后 blobBh表示提交Cb中d2/f2的文件。 如果提交 C c 有一个顶级树T5，该树引用名称为f3的Bh，则提交Cc将相同的文件内容存储在名称f3下(没有子文件夹)。
存储库中的对象持久性是一堆规则的功能，其主要驱动因素是可访问性。 有关可访问性的定义，请参阅像 (a) Git 一样思考。 无法访问的对象(通常，最终)将被删除，但附加规则会阻止在一段时间内删除无法访问的松散对象，以便 Git 可以创建临时对象，并最终(在时间段内)使它们可访问，从而永久(或永久，因为它们保持可访问)。
包中的对象根本无法删除。 但是，包含许多无用对象的包文件通常可以重新打包到新的(和不同的)包文件中;或者它们可以爆炸成单独的松散物体。 一旦不再需要旧的包文件(因为它的所有对象都可以作为松散对象或取代包)，就可以丢弃该文件，但包文件的.keep文件将阻止它被丢弃。 Git 本身不会创建.keep文件：它们适用于直接摆弄包文件(出于任何目的)的人。
git gc命令是一个包装器，通常负责创建和维护包文件以及清理过期的、未引用的松散对象。 它运行其他内部 Git 命令，包括git reflog expire、git repack和git prune来达到这个结果。