Оптимизация git-репо, содержащего большие двоичные файлы

21

Наш проект составляет около 11 ГБ, 10 из которых являются двоичными данными (.png изображения). Следовательно, операции a git diffили git statusзанимают больше минуты. К счастью, все файлы данных разделены на папки с чудесным именем data. Назначение: «Избегайте сжатия, различий и других дорогостоящих операций с двоичными файлами».

  • Рассматривалось разделение проекта на два репозитория. Тогда dataбудет внешний репо, который проверяется основным репо исходного кода. Было решено, что затраты на синхронизацию репозиториев будут слишком большими, особенно для исполнителей, работающих с файлами данных.

  • Говоря явно git, эти файлы являются двоичными , за исключением того, что были рассмотрены файлы из diffs , но они кажутся лишь частичным решением вопроса.

Я чувствую, что атрибуты git - это решение, но как? Или есть лучшая архитектура, чем монолитное РЕПО?

Vorac
источник
1
Первый большой вопрос здесь - насколько важны эти файлы данных. Нужны ли вашей программе все эти изображения, доступные для того, чтобы сделать что-нибудь полезное, или она может обойтись небольшим подмножеством во время типичной разработки / тестирования?
Ixrec
@Ixrec, изображения на самом деле важнее исходного кода. Все они должны присутствовать, и контрольные суммы .png всегда проверяются на наличие поврежденных файлов.
Vorac
1
Почему этот вопрос не о переполнении стека? Q. Кажется, точно подходит для этого.
Spirc
@spirc этот вопрос перекрывает грань между «помощью с программным инструментом», которая обсуждается в SO, и «стратегией контроля версий», которая обсуждается здесь. Так как он не спрашивает, какую команду git выполнить для выполнения чего-либо, он явно не находится на стороне SO, поэтому я проголосовал за то, чтобы оставить ее открытой здесь.
@ Снеговик спасибо за ответ. К какому пункту списка по теме это подходит? programmers.stackexchange.com/help/on-topic
spirc

Ответы:

18

Вы можете использовать git-lfs или аналогичные инструменты (git-fat, git-annex и т. Д.). Эти инструменты в основном заменяют двоичные файлы в вашем репо на небольшой текстовый файл с хешами и хранят фактические двоичные данные не git-способом - как сетевой ресурс.

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

Afaik git-lfs поддерживается github, gitlab, VisualStudio и является открытым исходным кодом.

kat0r
источник
2
Вы пытались использовать git-lfsв проекте много гигабайт ресурсов со смешанной командой разработчиков / художников? Мне интересно знать, используют ли люди git-lfs для таких проектов, как игры и анимация. Так как это все еще довольно новый на момент написания. Исходя из моего собственного опыта, барьер входа в git для менее технических пользователей уже очень высок, поэтому наличие дополнительного слоя для управления файлами поверх него может быть трудным для людей, если они уже не знакомы с git.
ideasman42
Извините, только для примерно 1 ГБ данных. Но git-lfs не должен добавлять дополнительных шагов для конечных пользователей, он должен быть полностью прозрачным.
kat0r
Кажется, это правильный ответ. Если в процессе интеграции возникнут некоторые проблемы, я сообщу здесь. Таким образом, процедуру установки необходимо выполнить только один раз на сервере, а не на каждом клиентском компьютере?
Vorac
Afaik вам нужно установить небольшой клиентский плагин, тоже проверьте страницу github. Но это должно быть легко внедрено с групповой политикой / проще, чем любая альтернатива.
kat0r
1

Используйте репозитории GIT и SVN

Если двоичные файлы могут быть логически отделены от источника, вы можете рассмотреть возможность использования git для текстовых файлов и не DVCS, такого как subversion для двоичных файлов.

Проект, над которым я работаю, делает это, так как у нас есть много ГБ для скомпилированных библиотек (для зависимостей OSX / Win32), которые мы должны поддерживать версионными.


С другой стороны, если у вас нетехнические пользователи, использование двух систем контроля версий может быть проблематичным. Однако, если художники не работают над кодом, вы можете предоставить скрипт для выполнения обновления, и они могут использовать subversion для фиксации бинарных ресурсов.

Используйте SVN (с git svn)

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

Это делает его немного более сложным для разработчиков, использующих git, но означает для всех, кто не знаком с DVCS (или VCS в целом), - они могут использовать простую модель SVN без необходимости использования нескольких сложных систем контроля версий.


git-lfs тоже вариант, но я не использовал его, поэтому не могу сказать, насколько хорошо он работает.

ideasman42
источник