我正在寻找如何处理我的源代码(web应用程序)依赖的大型二进制文件的意见。我们目前正在讨论几种替代方案:

Copy the binary files by hand. Pro: Not sure. Contra: I am strongly against this, as it increases the likelihood of errors when setting up a new site/migrating the old one. Builds up another hurdle to take. Manage them all with Git. Pro: Removes the possibility to 'forget' to copy a important file Contra: Bloats the repository and decreases flexibility to manage the code-base and checkouts, clones, etc. will take quite a while. Separate repositories. Pro: Checking out/cloning the source code is fast as ever, and the images are properly archived in their own repository. Contra: Removes the simpleness of having the one and only Git repository on the project. It surely introduces some other things I haven't thought about.

你对此有什么经验/想法?

还有:有人有在一个项目中使用多个Git存储库并管理它们的经验吗?

这些文件是用于生成包含这些文件的pdf文件的程序的图像。这些文件不会经常更改(例如几年),但它们与程序非常相关。没有这些文件,程序将无法工作。


当前回答

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

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

其他回答

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

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

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

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

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

我正在寻找如何处理我的源代码(web应用程序)依赖的大型二进制文件的意见。你对此有什么经验/想法?

当我的web应用程序二进制数据超过3gb时,我个人在我的一些云主机上就遇到过Git同步失败的情况。我当时考虑过BFT回购清洁,但感觉像一个黑客。从那时起,我开始将文件置于Git的权限之外,而是利用专门构建的工具(如Amazon S3)来管理文件、版本控制和备份。

有人有在一个项目中使用多个Git存储库并管理它们的经验吗?

是的。雨果主题主要是这样管理的。这有点滑稽,但它能完成任务。


我的建议是选择适合这项工作的工具。如果它是为一个公司,你在GitHub上管理你的代码线,付钱并使用Git-LFS。否则,您可以探索更有创意的选项,例如使用区块链进行分散加密文件存储。

需要考虑的其他选项包括Minio和s3cmd。

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

我将使用子模块(如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克隆”会更快。