一个Git仓库可以处理的提交数量是否存在上限？

Question

我想知道Git仓库能处理的提交数量是否有上限。

目前我正在进行一个单人项目，我在本地编码，使用Git提交/推送更改，然后在我的开发服务器上拉取这些更改。

我将它视为比在本地工作并通过FTP上传更改更容易的替代方式...幸运或不幸的是，这是如此简单的工作流程，以至于在编码时我会经历许多次编辑/提交/推送/拉取/浏览器刷新循环。

我想知道这样做是否会在某个时候给我带来麻烦。 如果可能成为问题，我想知道如何避免这种麻烦...似乎rebase可能是解决方法，特别是因为我不必担心冲突分支等问题。

- James Chevalier

---

Git可以扩展到整个Linux内核（这就是它被创造出来的目的）。所以，除非你有数百MB的代码和十年的提交历史记录，否则不用担心。 - Spike Gronim

Answer 1

“上限”可能是SHA1碰撞发生的点，但由于SHA码有40个十六进制数字（16^40 ≈ 1.4x10^48种可能性），其概率非常接近于零，甚至不值一提。因此，在未来数千年内，您几乎没有任何问题的可能性几乎为零。

夸张的例子（仅供娱乐）：每分钟提交1个更改（只更改一个文件->使用三个新的SHA（文件、提交、树）=每分钟使用3个新SHA =……=每年使用1.6M SHA =每千年16亿SHA =每千年使用1x10^-37% ……（如果每分钟有1000个文件/提交，则仍为3.6x10^-35%）。

话虽如此，如果您想清理历史记录，使用rebase压缩它们可能是最好的选择。只要确保您已公开共享了存储库，就可以理解其含义。

在重新设定基础后，您可能还需要进行垃圾回收以释放一些空间（但首先确保重新设置基础正确，并且您可能需要告诉它收集所有东西，否则默认情况下将不会收集任何两周内未使用的内容）。

- johnny

---

就像 GUID 和 UUID 一样，这仍然是可能的。 - Chhorn Elit

好的，我理解这一点。但在具体的Git实现中，是否有一个类似于long amount=Count(GetCommitsWithCertainProperties(x,y))的地方，如果提交超过2^32个，则操作会失败？ - anion

还有，当涉及到碰撞时，不要忘记生日悖论。但即使发生碰撞，在重试提交时，时间戳会有所不同，哈希值也会不同。因此，即使发生碰撞，您仍然可以提交并且一切都应该正常工作。 - InDieTasten

根据此计算器显示，160位哈希的碰撞概率在至少1e21次提交后为6σ（即1e-7）。 - Mateen Ulhaq

Linux内核显然在2020年通过了100万（1e6）次提交。我很好奇GitHub上有多少“总”提交，跨越“所有存储库”...我上面的例子表明，在“1000年”内有1.6B（1.6e9）次提交。那个双曲线的例子仍然远离1e21。是的，生日悖论意味着它不是一个原始百分比。上面的计算并未显示“碰撞”的概率，只是计算（/“使用”）哈希数的数量。最终结果是相同的-不要担心碰撞。 - johnny

Answer 2

我相信你完全不用担心 :)

Git使用SHA-1哈希算法来检查文件，哈希冲突的概率非常小。所以尽情使用吧！！

我个人每天提交大约30次而没有出现问题。

但是要避免对二进制文件进行版本控制 :)，这对于它而言真的很沉重。

- ykatchou

Answer 3

我认为git能够处理的提交数量没有明显的限制，只取决于你个人的消化能力。在大型项目和多个开发者的情况下，你会看到比自己生成的更多的活动。

如果你愿意，可以保留一个次要分支，每周合并一次，但是git不会关心你有多少提交。只要你能理解自己在做什么，就可以尽情提交。你总是可以回溯几个提交或使用类似bisect的工具来解决历史问题。

- Jeff Ferland