我打算将我们的存储库从SVN移到Git，我听到很多关于Git如何处理二进制文件的效率非常低。但我真的不明白我将在这个主题上遇到的问题（除了存储库大小），因为我们的存储库中确实有很多二进制文件。
这是我们的情景： 我们有一个800MB的存储库，包含2个目录：
这是考虑没有历史的当前大小（让我们假设我们从头开始Git仓库，没有任何历史记录）。
二进制文件永远不会超过25MB，大多数低于10MB，并且很少更改（一年2或3次）。
使用Git时，我可以期待像这样的存储库问题吗？如果Git的唯一问题是所有历史记录都保存在每个本地存储库中，那么我不希望它增长太多，因为这些文件不会经常更改。
但是Git性能（提交或检查状态时）可能会受到存储库中存在lof二进制文件这一事实的影响吗？ Git子树可以提供帮助吗（通过使目录“libs”成为主存储库的子树）？
编辑：我知道我可以使用像Maven这样的东西来存储这些二进制文件，但是我们在这里有一个限制，我们必须将这些文件保存在一起。
更新：我做了一系列测试，我得出结论，Git足够智能分析zip内容并保存增量：例如，如果我添加一个20MB的zip文件，然后我修改zip中的一个文本文件，当我提交新版本的zip并运行'git gc'时，大小几乎没有变化（仍然有20MB）。所以我可以假设Git与zip文件一起正常工作。有人可以证实这一点吗？
答案 0 :(得分：2)
您可能遇到的主要问题是每个git存储库都存储所有文件的完整历史记录。即使它们被打包在一起，也没有简单的方法可以对源文件只有一个子目录进行“轻量级”检查，这需要您进行处理。
如果您有500 MB的二进制文件，每年更改2-3次，这意味着三年后，您需要处理3 GB以上的历史记录（好的，压缩一点），每当您签出回购或把它放在某个地方。这可能会有点刺激。
根据我的经验，git子模块在这方面并不是一个巨大的帮助：你仍然有文件的git repo（即一个庞大且不断增长的存储库），而子模块大多使事情变得复杂。最好的方法是尽量避免使用大型二进制文件，例如存储用于构建它们的源代码（如果花费的时间太长，可能会将它们缓存在某个地方）。
尽管如此，git肯定会在你的用例中存活下来，所以如果你不介意一点磁盘空间就可以试一试。
答案 1 :(得分：-1)
你看到大小与git（与svn相比）有所不同的主要原因是因为git和svn的构建方式不同。
Svn： 为了处理文件，svn使用增量。即，第一次提交文件时，svn会创建文件，当您提交修改时，svn仅存储两个文件之间的差异。 如果我没记错（并且确切地说），svn会存储您提交的最后一个文件，并且会负面存储这些增量。当你几乎没有修改并且想要获得HEAD提交时，这是非常快的，但是你将获得的修订越多，获取特定修订的速度就越慢，因为svn将不得不使用增量。
GIT： Git以与svn完全不同的方式工作。它不存储增量，它存储blob（二进制大对象）。提交文件时，它会将文件存储在带有修订标签的blob中。如果您在不修改文件的情况下提交，git会为之前提交的blob创建一个符号链接。如果修改文件，git会存储完整的blob。 这样做的优点是每个版本都同样快，但是您的存储库可以快速增长。
我不会回答如何处理二进制文件，因为我相信这完全存在于互联网上（我确信它是在SO上）。
我希望它能帮到你