我最近发现了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上有一个软件包。

在我看来，如果您可能经常修改这些大文件，或者您打算进行大量的git克隆或git签出，那么您应该认真考虑使用另一个git存储库(或者可能是访问这些文件的另一种方法)。

但是如果您像我们一样工作，并且您的二进制文件不经常修改，那么第一次克隆/签出将会很长，但是在那之后它应该和您想要的一样快(考虑到您的用户一直使用他们拥有的第一个克隆存储库)。

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

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

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

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

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

我将使用子模块(如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-fat。我喜欢它只依赖于stock Python和rsync。它还支持通常的Git工作流，使用以下自解释命令:

git fat init
git fat push
git fat pull

此外，您需要将.gitfat文件签入存储库，并修改.gitattributes以指定您希望gitfat管理的文件扩展名。

您可以使用普通的git add添加一个二进制文件，它会根据您的gitattributes规则调用git fat。

最后，它还有一个优点，即二进制文件实际存储的位置可以跨存储库和用户共享，并支持rsync所做的一切。

更新:如果你正在使用Git-SVN网桥，不要使用git-fat。它最终将从Subversion存储库中删除二进制文件。但是，如果您使用的是纯Git存储库，那么它的工作效果非常好。