Git和二进制数据 [英] Git and binary data

问题描述

我目前开始为我的版本控制系统使用git，但是我做了一些网页/游戏开发，当然需要存储图像（二进制数据）。所以如果我的理解是正确的，如果我提交图像并且它改变了100次，如果我获取该回购的新副本，我基本上会检查该二进制文件的所有100个修订版本吗？

I'm currently starting to use git for my version control system, however I do a fair bit of web/game development which of course requires images(binary data) to be stored. So if my understanding is correct if I commit an image and it changes 100 times, if I fetch a fresh copy of that repo I'd basically be checking out all 100 revisions of that binary file?

这对于大型回购商来说不是一个问题，图像经常变化，回购商的最初购买量不会变得相当大？有没有人在现实世界中遇到过这个问题？我已经看到了一些替代方案，例如使用子模块并将图像保存在独立的回购库中，但这只会使代码库更小，图像回购将仍然很大。基本上，我只是想知道是否有一个很好的解决方案。

Is this not an issue with large repo's where images change regularly wouldn't the initial fetch of the repo end up becoming quite large? Has anybody experienced any issue's with this in the real world? I've seen a few alternatives for instance, using submodules and keeping images in a separate repo but this only keeps the codebase smaller, the image repo would still be huge. Basically I'm just wondering if there's a nice solution to this.

推荐答案

我不会称之为checkout，但是的，你第一次获取版本库，只要二进制数据是巨大的，不可压缩的，它将会是什么 - 巨大的。是的，因为自然保护法仍然有效，将它分解成模块并不会节省您在初次提取存储库时的空间和时间。

I wouldn't call that "checkout", but yes, the first time you fetch repository, provided that binary data is huge and incompressible it's going to be what it is - huge. And yes, since conservation law is still in effect breaking it into modules won't save you space and time on initial pulling of repository.

一种可能的解决方案仍然是使用单独的资源库和 - 深度选项。浅存储库有一些限制，但我不记得具体是什么，因为我从来没有使用它。检查文档。关键字是浅。

One possible solution is still using separate repository and --depth option when pulling it. Shallow repositories have some limitations, but I don't remember what exactly, since I never used it. Check the docs. Keyword is "shallow".

编辑：从 git-clone（1） ：

Edit: From git-clone(1):

一个浅仓库有许多
限制（你不能克隆或获取
，也不能推从也不到它），
，但如果你只是
对一个历史悠久的
大型项目的近期历史感兴趣，并且
想要发送修复作为
补丁。

A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.

这篇关于Git和二进制数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！