我正在寻找如何处理我的源代码(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文件的程序的图像。这些文件不会经常更改(例如几年),但它们与程序非常相关。没有这些文件,程序将无法工作。
我将使用子模块(如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克隆——过滤从git 2.19 +浅克隆
这个新选项可能最终会成为二进制文件问题的最终解决方案,如果Git和GitHub开发并使其足够友好(他们可以说仍然没有实现子模块例如)。
它实际上只允许为服务器获取您想要的文件和目录,并与远程协议扩展一起引入。
有了这个,我们可以先做一个浅克隆,然后自动使用构建系统为每种类型的构建获取哪些blobs。
甚至已经有一个——filter=blob:limit<size>,它允许限制读取的最大blob大小。
我提供了一个关于该特性的最小详细示例:如何克隆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存储库,那么它的工作效果非常好。