git提交所用的时间是否取决于文件大小？另外，在git中恢复以前的版本需要多长时间？

是否有固定的时间长度来执行git提交，或者它取决于我们提交的文件？另外，git恢复以前的版本需要多长时间？

git commit命令写入一些树对象和一个commit对象，然后将一个commit对象的哈希ID存储到当前分支中。树对象集由索引的内容决定。您可以使用

gitls文件--stage

直接查看这些内容

编写这些对象所需的时间通常很短，因此在大多数情况下，

git commit

几乎是即时的。所需的树对象数量取决于索引内容所需的子树数量。这是很难计算的。检查索引中文件名中斜杠的数量是一个开始，但是如果索引包含文件

a/b

，

a/c

，等等，通过

a/z

，这只是所有这些文件的一个子树（对于

a/

）。如果索引包含

a/b/c

和

a/c/d

，则有一个子树用于

b/

，一个子树用于

c/

，不包含

a/

，再加上

a/

本身的树，总共有三棵树。所以，仅仅计算斜杠就高估了，有时甚至是疯狂地高估了，这取决于每个子树的填充情况

请注意，在运行

Git commit

时，文件本身已经以压缩的Git-only格式存储。如果您检查

gitls文件--stage

输出，您将看到每个文件都有一个丑陋的hash ID。该散列ID表示已将文件内容存储在存储库中的blob对象。git commit命令仅引用现有内容：不需要编写新文件

---

（将文件从存储库中复制出来所需的时间，从其特殊的压缩Git-only表单复制到磁盘上的普通表单，大致与文件的大小成正比。在

Git add

期间，将文件从磁盘上的普通表单复制到存储库所需的时间也大致与文件的大小成正比。但一旦进入，提交读取文件非常快。切换到具有相同版本文件的另一个提交不需要时间，因为Git注意到索引和工作树中的文件与目标提交中的文件匹配。切换到具有不同版本文件的提交需要将文件从提交和索引提取到工作树中，f进入“从存储库复制到普通表单”案例。）

这取决于分支大小。但通常不会超过2分钟。请阅读其中直接讨论了您心中的疑问。执行Git提交不一定取决于文件大小，而是取决于您的repo中尚未出现的新内容的大小。因此，假设出现了一个全新的文件，则提交所需的时间将比提交相对较小的新文件所需的时间更长。另一个变量是：您将推/拉到/从何处？如果您只是在谈论您的本地存储库，则所有内容都应该非常简单instantaneous@Kai提交总是本地的，OP没有提到推/拉。你甚至不需要这样做有一个远程使用git。@Romanvaleri是的，很明显。OP问的是时间，这甚至不是提交的一个因素，但与远程报告相关。谢谢！