对于 git 存储库来说，多少个对象才算太多？

Question

我们计划将经常更新的文本和图形存储在版本控制系统中。它不是源代码，但主要是文本文件。没有一个对象是“大”的，但频繁更新会导致存储库的大小变大。

与其他版本控制系统相比，我如何判断版本历史的大小是否太大而导致 git 无法实际使用。

更新：这不是问题的答案。但是，就我的目的而言，使用 clone --shallow-since=... 可能会有效，因为它基于观察存储库随时间的增长情况，而不需要回答“有多少个对象”。

Answer 1

提前考虑

在启动存储库之前，您需要决定一件事：

• 我能改写历史吗？

如果可以的话，那么当遇到性能问题时，你可以改变历史记录，这样就不需要计划了尽可能多如果你 不能重写历史，那么您需要了解存储库如何增长以及 Git 将如何处理它。

存储库分析和 Git 限制信息

git-sizer由 GitHub 制作，可以随着存储库的发展对其进行分析。它还包含有关 Git 限制的文档。

再增加一层间接层

处理较大文件的标准方式似乎是添加一个间接层。例如，您可以使用git 附件它允许您创建指向某些被视为“大”文件的符号链接。

文件数量

我在使用 git-annex 时确实遇到了问题，因为我有很多文件。git-annex有fsck一个子命令，用于检查文件损坏。该命令可能需要几个小时才能完成。它可能git-annex有一个直接的解决方案，但我最终做的是将不再需要访问的文件目录归类。