Git и двоичные данные

Question

В настоящее время я начинаю использовать git для своей системы контроля версий, однако я занимаюсь разработкой веб-игр / игр, которая, конечно, требует хранения изображений (двоичных данных). Так что, если мое понимание верно, если я фиксирую изображение, и оно меняется 100 раз, если я получу свежую копию этого репо, я в основном проверю все 100 ревизий этого двоичного файла?

Разве это не проблема с большими репо, когда изображения регулярно меняются, разве начальная выборка репо не станет достаточно большой? Кто-нибудь испытывал какие-либо проблемы с этим в реальном мире? Например, я видел несколько альтернатив: использование субмодулей и хранение изображений в отдельном репо, но это только уменьшает кодовую базу, репо изображений все равно будет огромным. По сути, мне просто интересно, есть ли хорошее решение для этого.

Answer 1

Я бы не назвал это «извлечением», но да, при первом получении хранилища при условии, что двоичные данные огромны и несжимаемы, они будут такими, какие они есть - огромными. И да, поскольку закон сохранения все еще действует, разбивая его на модули, вы не сэкономите место и время при первоначальном извлечении хранилища.

Одним из возможных решений по-прежнему является использование отдельного хранилища и опции --depth при его извлечении. У мелких репозиториев есть некоторые ограничения, но я не помню, что именно, так как я никогда не использовал их. Проверьте документы. Ключевое слово "мелкий".

Редактировать : С git-clone(1):

Мелкий репозиторий имеет ряд ограничения (вы не можете клонировать или получить от этого, ни толкать, ни в это), но достаточно, если вы только заинтересованы в недавней истории большой проект с длинной историей, и хотел бы отправить исправления как пластыри.

Answer 2

Что я делаю, это делаю изображения игнорируемыми / не отслеживаемыми каталогами, а затем синхронизирую каталоги / каталоги изображений, используя другие, не git-системы (или просто вручную копирую изменения каталога изображений один раз, когда вы говорите о большом количестве изображений что вам не нужно полностью синхронизироваться).

Answer 3

К сожалению, git на самом деле не предназначен для хранения двоичных данных. Поскольку он распространяется, вы будете извлекать все версии всех файлов всякий раз, когда его клонируете. Также становится невероятно сложно удалить эти большие двоичные файлы из вашего хранилища кода. Подробнее об этом здесь: (http://www.somethingorothersoft.com/2009/09/08/the-definitive-step-by-step-guide-on-how-to-delete-a-directory-permanently-from-git-on-widnows-for-dumbasses-like-myself/).

Я бы порекомендовал попробовать его, но храните двоичные файлы отдельно от кода (т. Е. Используя подмодули). В этом случае, если это не сработает для вас, вы можете использовать другое решение, не переписывая всю историю для вашего основного хранилища.

Answer 4

Здесь обсуждается большое файловое хранилище с GIT: http://blog.deveo.com/storing-large-binary-files-in-git-repositories/

Я наткнулся на этот SO вопрос в рамках своего исследования и подумал, что я бы указал людям на запись в блоге, которую я уже рассмотрел (предупреждение от спойлера, они рекомендуют git-annex для не-окон пользователи). ,