git - git 在用户/代码库大小方面的扩展性如何？

Question

我们目前正在使用由约 50 位活跃开发人员共享的约 600MB（即 .git 目录的大小）的单个 git 存储库。

随着我们的代码库和开发人员基础的增长，由于代码量（缓慢的 git 状态）和推送量（推送到 master 被拒绝，因为同时其他人已经推送），这种方法似乎最终将变得不可持续。

我的问题是，当前解决方案在 (1) 代码量方面的扩展性如何？(2) 有多少活跃的开发者？

是否有使用 git 的方法（例如大量使用功能分支）或特定技术可以帮助 git 扩展而不牺牲单个共同历史？

谢谢！

Answer 1

大量用户没有问题。证明是 linux 在 git 下。

但是您的存储库的大小让我怀疑您不尊重许多 VCS 的这条重要规则：不要将二进制文件放入其中。您无法有效地计算二进制文件中的差异，这使得存储库快速增长。

如果某些大变化元素的本机源格式是二进制的（通常是一些文档或媒体），那么如果大小有问题，您可能应该在 VCS 之外管理该部分。

还应该注意的是，git 并没有真正定义你的工作方式。如果所有编码人员都直接推送到同一个存储库和同一个分支，那么你就有问题了。如果某些代码管理器获取更改并将它们推送到中央存储库，那么您就没有问题。不要忘记 git 是一个去中心化的 VCS。

Answer 2

Git 是由Linus Torvalds明确创建的，用于处理 Linux 内核的开发。这考虑了贡献项目的用户数量以及因此而创建的提交数量。

如此规模的项目是否易于维护在很大程度上取决于您的工作流程。如果您只使用每个人都使用的几个开发分支，您可能最终会遇到多个合并冲突。另一方面，如果开发在（功能）分支上高度分离，那么维护它会变得容易得多，因为您只需要在此类分支上的工作完成并且可以合并工作时触摸您的主线。您通常让具有特殊集成者角色的人专注于这一点。在 Linux 内核的情况下，您也有副手从开发人员那里收集（和验证）提交，然后将其提交给独裁者（Linus 本人），然后由他决定实际进入内核的内容。

Overall though, there is nothing that prevents you from having a huge project within Git. Depending on your situation it might be worth though to split it up if it’s possible (compare with Android’s OSP which has a large number of smaller repositories).

Note that a large repository size will not affect your workflow aside from the initial cloning process. Unless you have a ridiculous large working directory (which would affect any source control system), it will not affect the normal speed of Git. All commands run locally, and things like git status will only need to look at the working directory, the index and the current version, i.e. that will not change if the history is longer. As Git’s data model is a directed acyclic graph, you will have most things you need instantly, regardless of how big your graph is beyond the accessors you use (branch pointers, HEAD etc.).

That being said, 600 MB for your repository is really a lot. I suspect that you have many binary files in it, which might not be the best idea. While Git handles binary files in the same way as text files, the compression Git will not, and the default gzip compression which is applied to every Git object is often not helpful for binary files (like images which are already compressed) as well. So you might want to look into a different solution for your assets if that’s possible.