我想知道git存储库可以处理的提交数量是否有上限。
在我正在进行的一个独立项目中，我一直在本地编码，提交/推送git中的更改，然后在我的开发服务器上提取更改。
我认为这是在本地工作和通过FTP上传更改的更简单的替代方案...幸运/不幸的是，这是一个如此简单的工作流程，我有时会通过许多编辑/提交/推/拉/编码时浏览器刷新周期。
我想知道这是否会转过来让我陷入某种困境。如果它可能是一个问题，我想知道如何避免这种麻烦...似乎可能是一个转折点，特别是因为我不必担心分支冲突等等。
答案 0 :(得分：14)
“上限”很可能是发生SHA1碰撞的点，但由于SHA长度为40个十六进制数字（16 ^ 40~1.4x10 ^ 48种可能性），因此它的可能性非常接近零。甚至都不好笑。因此，至少在接下来的几千年里，你几乎有百分之百的机会遇到任何问题。
双曲线示例（只是为了好玩）：1次提交/分钟（只更改一个文件 - ＆gt;使用三个新的SHA（文件，提交，树）=使用3个新shas / minute = ... = 1.6M shas使用/ year = 16亿shahs / millennia = 1x10 ^ -37 ％使用每个millenia ...（1000个文件/ commmit / min，它仍然是3.6x10 ^ -35％）
话虽这么说，如果你想要清理你的历史，用rebase压制它们可能是你最好的选择。如果您公开分享回购，请确保了解其含义。
您可能还希望在重新定位后进行垃圾收集以释放一些空间（确保首先使用rebase，但是您可能需要告诉它收集所有内容，否则默认情况下不会收集任何新内容。两周大。）
答案 1 :(得分：5)
我很确定你根本不必担心：）
Git使用SHA-1哈希来检查文件，哈希冲突的概率接近于零。所以玩得开心!!
我个人每天约30次提交，没有问题。
但是要避免对二进制文件进行版本控制:)它真的很重要。
答案 2 :(得分：3)
我认为git可以处理的提交数量没有很大的限制，只有你可以个人消化的内容。对于较大的项目和多个开发人员，您将看到比您自己生成的活动更多的活动。
如果您愿意，您可以保留每周合并的辅助分支，但是git永远不会关心您拥有多少提交。只要你能理解你在做什么，就去疯狂。你总是可以提交几个提交，或者使用像bisect这样的工具来找出历史问题。