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

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

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

看看camlistore。它不是真正基于git的，但我发现它更适合您必须做的事情。

我最近发现了git-annex，我觉得很棒。它是为有效地管理大文件而设计的。我用它来收集我的照片/音乐(等)。git-annex的开发非常活跃。文件的内容可以从Git存储库中删除，Git只跟踪树的层次结构(通过符号链接)。然而，要获得文件的内容，在拉/推之后需要第二步，例如:

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

有很多可用的命令，网站上有很好的文档。Debian上有一个软件包。

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

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

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

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

Git LFS就是答案

# Init LFS
git lfs install
git lfs track "large_file_pattern"

# Then follow regular git workflow
git add large_file
git commit -m "Init a very large file"
git push origin HEAD

在后台，git lfs会创建一个对你的大文件的引用，而不是直接存储在git repo中

欲了解更多信息:https://git-lfs.github.com/

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

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

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

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

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

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