我正在寻找如何处理我的源代码(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 bup,这是一个git扩展,可以聪明地在git存储库中存储大型二进制文件。

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

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

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

其他回答

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

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

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

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

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

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

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

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

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

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

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

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