git存储库可以处理的提交数量是否有上限？ [英] Is there an upper limit to the number of commits a git repository can handle?

问题描述

我想知道git存储库可以处理的提交次数是否有上限。

I'm wondering if there's an upper limit to the number of commits that a git repository can handle.

在一个单独的项目中，我现在正在工作，我一直在本地编码，在git中提交/推送更改，然后将更改拉到我的开发服务器上。

In a solo project I'm working on right now, I've been coding locally, committing/pushing changes in git, then pulling the changes on my development server.

我将其视为比在本地工作和通过FTP上传更改...幸运的/不幸的是，这样的工作流程如此简单，我有时在编码时会经历许多编辑/提交/推送/拉/浏览器刷新周期。

I treat this as an easier alternative to working locally and uploading changes via FTP... Fortunately/Unfortunately it's such an easy workflow that I sometimes go through many edit/commit/push/pull/browser-refresh cycles while coding.

我想知道这是否会转过身来咬我。如果这很可能是个问题，我想知道如何避免这种麻烦……似乎需要改组为基础，尤其是因为我不必担心分支机构之间的冲突等。

I'm wondering if this is going to turn around and bite me somewhere down the line. If it's likely to be a problem, I'm wondering how I can avoid that trouble ... It seems like a rebase might be the way to go, especially since I won't have to worry about conflicting branches etc.

推荐答案

上限很可能是发生SHA1冲突的点，但是由于SHA的长度为40个十六进制数字（ 16 ^ 40〜1.4x10 ^ 48种可能性），它几乎为零可能性，甚至都不有趣。因此，至少在接下来的几千年中，您大约有百分之零的机会会遇到任何问题。

Well the "upper limit" would likely be the point at which a SHA1 collision occurs, but since the SHAs are 40 hexadecimal digits long (16^40 ~ 1.4x10^48 possibilities), it's so close to zero possibility that it's not even funny. So there's roughly a zero percent chance you'll have any problems for at least the next several millennia.

双曲线示例（仅出于娱乐目的）：1次提交/分钟（仅更改一个文件->使用了三个新的SHA（文件，提交，树）=使用了三个新的SHA /分钟= ... =使用了160万个SHA /年= 16亿个shah /千年= 1x10 ^ -37 ％使用了每一个千年…（以1000个文件/提交/分钟的速度，仍然是3.6x10 ^ -35％）

Hyperbolic Example (just for fun): 1 commit/minute (just changing one file -> three new SHAs used (file, commit, tree) = 3 new shas used / minute = ... = 1.6M shas used / year = 1.6 Billion shahs / millennia = 1x10^-37 % used each millenia... (at 1000 files/commmit/min, it's still 3.6x10^-35%)

话虽如此，如果您想清理您的历史记录，用rebase压缩它们可能是您最好的选择。只要完全公开共享该repo，请确保您了解其中的含义。

That being said, if you want to clean up your history, squashing them down with rebase is probably your best bet. Just make sure you understand the implications if you've shared the repo publicly at all.

您可能还需要在重新设置基准以释放一些空间后进行垃圾收集（不过，请确保重新基准首先正确运行，并且您可能需要告诉它收集所有内容，否则默认情况下它将不收集任何两周以上的新内容）。

You might also want to garbage collect after rebasing to free up some space (make sure the rebase worked right first, though, and you might need to tell it to collect everything or it will, by default, not collect anything newer than two-weeks old).

这篇关于git存储库可以处理的提交数量是否有上限？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！