我正在寻找如何处理我的源代码(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 2.19 +浅克隆

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

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

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

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

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

其他回答

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

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

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

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

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


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

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

你也可以用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存储库,那么它的工作效果非常好。

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

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

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

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

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