如果没有这些文件程序就不能工作，那么将它们分割成一个单独的repo似乎是一个坏主意。我们有大型的测试套件，我们将它们分解到一个单独的repo中，但这些都是真正的“辅助”文件。

但是，你可以在一个单独的repo中管理这些文件，然后使用git-submodule以一种合理的方式将它们拉到你的项目中。你仍然有所有源代码的完整历史但是，据我所知，你只有图像子模块的一个相关修订。git-submodule功能应该帮助您保持正确的代码版本与正确的图像版本保持一致。

下面是Git Book中关于子模块的一个很好的介绍。

看看git bup，这是一个git扩展，可以聪明地在git存储库中存储大型二进制文件。

您希望将它作为子模块使用，但不必担心存储库变得难以处理。他们的一个示例用例是在Git中存储VM映像。

实际上我还没有看到更好的压缩率，但我的存储库中并没有真正大的二进制文件。

你的里程可能会有所不同。

自2015年4月以来，另一个解决方案是Git大文件存储(LFS)(由GitHub开发)。

它使用git-lfs(参见git-lfs.github.com)，并使用支持它的服务器进行测试: 您只能将元数据存储在git repo中，将大文件存储在其他地方。

SVN似乎比Git更有效地处理二进制增量。

我必须决定文档的版本控制系统(JPEG文件、PDF文件和.odt文件)。我刚刚测试了添加一个JPEG文件并将其旋转90度4次(以检查二进制增量的有效性)。Git的存储库增长了400%。SVN的存储库仅增长了11%。

因此，看起来SVN使用二进制文件更有效率。

所以我选择Git作为源代码，SVN作为文档之类的二进制文件。

我将使用子模块(如Pat Notz)或两个不同的存储库。如果你太频繁地修改二进制文件，那么我会尽量减少巨大的存储库清理历史记录的影响:

几个月前我遇到了一个非常类似的问题:~21 GB的MP3文件，未分类(糟糕的名称，糟糕的id3，不知道我是否喜欢这个MP3文件……)，并在三台计算机上复制。

我使用带有主Git存储库的外部硬盘驱动器，并将其克隆到每台计算机中。然后，我开始用习惯的方式对它们进行分类(推、拉、合并……)多次删除和重命名)。

最后，我只有~ 6gb的MP3文件和~83 GB的.git目录。我使用git-write-tree和git-commit-tree创建了一个新的提交，没有提交祖先，并启动了一个指向该提交的新分支。该分支的“git日志”只显示了一次提交。

然后，我删除了旧的分支，只保留了新的分支，删除了ref-logs，并运行“git prune”:在那之后，我的.git文件夹只重约6gb…

你可以不时地用同样的方法“清除”这个巨大的存储库:你的“git克隆”会更快。

git克隆——过滤从git 2.19 +浅克隆

这个新选项可能最终会成为二进制文件问题的最终解决方案，如果Git和GitHub开发并使其足够友好(他们可以说仍然没有实现子模块例如)。

它实际上只允许为服务器获取您想要的文件和目录，并与远程协议扩展一起引入。

有了这个，我们可以先做一个浅克隆，然后自动使用构建系统为每种类型的构建获取哪些blobs。

甚至已经有一个——filter=blob:limit<size>，它允许限制读取的最大blob大小。

我提供了一个关于该特性的最小详细示例:如何克隆Git存储库的子目录?