Управление большими двоичными файлами с помощью Git


523

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

  1. Скопируйте двоичные файлы вручную.
    • Pro: Не уверен.
    • Против: я категорически против, так как это увеличивает вероятность ошибок при настройке нового сайта / переносе старого. Создает еще одно препятствие, чтобы принять.
  2. Управляйте ими всеми с помощью Git .
    • Pro: Удаляет возможность «забыть» скопировать важный файл
    • Противоположность: раздувает хранилище и снижает гибкость управления базой кода, а извлечение, клонирование и т. Д. Займет довольно много времени.
  3. Отдельные репозитории.
    • Pro: извлечение / клонирование исходного кода выполняется быстро, как всегда, и изображения должным образом архивируются в своем собственном хранилище.
    • Против: Удаляет простоту наличия единственного репозитория Git в проекте. Это, безусловно, вводит некоторые другие вещи, о которых я не думал.

Что вы думаете об этом?

Также: есть ли у кого-нибудь опыт работы с несколькими Git-репозиториями и управления ими в одном проекте?

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


26
А как насчет того, когда необходим контроль версий двоичного файла? Я думаю о командах художников, работающих над активами.
Дан

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

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


Ответы:


177

Если программа не работает без файлов, кажется, что разбивать их на отдельные репозитории - плохая идея. У нас есть большие тестовые наборы, которые мы разбиваем на отдельные репозитории, но это действительно «вспомогательные» файлы.

Тем не менее, вы можете управлять файлами в отдельном репозитории, а затем использовать их git-submoduleдля встраивания их в ваш проект в разумной форме. Таким образом, у вас все еще будет полная история всего вашего источника, но, насколько я понимаю, у вас будет только одна соответствующая ревизия вашего подмодуля изображений. git-submoduleСредство должно помочь вам сохранить правильную версию кода в соответствии с правильной версией изображения.

Вот хорошее введение в подмодули из Git Book.


11
«насколько я понимаю, у вас будет только одна соответствующая ревизия вашего подмодуля изображений». Я не думаю, что это правильно.
Робин Грин

22
Верно. Подмодуль - это полный Git-репозиторий, который просто оказывается вложенным в родительский репозиторий. Он знает всю свою историю. Вы можете делать это реже, но если вы храните в нем те же вещи, что и в родительском, у него будут те же проблемы, что и у родительского.
Каскабель

5
Это довольно плохое решение, если у вас есть большие двоичные файлы, которые меняются через определенный промежуток времени. У нас есть ужасно раздутый репозиторий, потому что новый бинарный файл хранится в нем при каждой сборке. Если вы не используете Windows, как указано ниже, приложение является хорошим решением. Если вы на Windows ... просто придется продолжать искать.
А.А. Грапсас

4
Другая проблема наличия больших бинарных файлов в репо - это производительность. Git не предназначен для работы с большими двоичными файлами, и как только размер репо возрастает до 3G +, производительность быстро падает. Это означает, что наличие больших двоичных файлов в репо ограничивает ваши возможности хостинга.
zoul

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

310

Недавно я обнаружил git-annex, который я нахожу потрясающим. Он был разработан для эффективного управления большими файлами. Я использую его для своих фото / музыкальных (и т. Д.) Коллекций. Разработка git-приложения очень активна. Содержимое файлов может быть удалено из репозитория Git, Git отслеживает только древовидную иерархию (через символические ссылки). Однако, чтобы получить содержимое файла, необходимо выполнить второй шаг после извлечения / нажатия, например:

$ git annex add mybigfile
$ git commit -m'add mybigfile'
$ git push myremote
$ git annex copy --to myremote mybigfile ## This command copies the actual content to myremote
$ git annex drop mybigfile ## Remove content from local repo
...
$ git annex get mybigfile ## Retrieve the content
## or to specify the remote from which to get:
$ git annex copy --from myremote mybigfile

Доступно много команд, и на сайте есть отличная документация. Пакет доступен в Debian .


11
Вау! Upvote для удивительности! Это реализует идею, которая у меня была недавно, и многое другое. В Хаскеле написано не меньше. Кстати, git-media - хорошая альтернатива.
cdunn2001

33
Но приложение не поддерживает Windows. Что проблематично для разработчиков игр.
А.А. Грапсас

7
Я слышал, что Steam отказывается от поддержки Windows и добавляет поддержку Linux ...;) серьезно, насколько сложно это портировать? Я думаю, что ваш средний разработчик игр мог бы сделать это.
Сэм Уоткинс

4
@EstebanBrenes Настоящим нарушителем условий является то, что в обычной конфигурации символические ссылки Windows требуют повышенных привилегий для создания.
Лорен Холст

4
Я только что нашел эту страницу . В нем говорится, что теперь git annexдоступно и для Windows . Если кто-нибудь когда-либо тестировал его в Windows, я хотел бы услышать о его или ее опыте!
Куичи К. Накамура

49

Еще одно решение, с апреля 2015 года - Git Large File Storage (LFS) (от GitHub).

Он использует git-lfs (см. Git-lfs.github.com ) и тестируется на сервере, поддерживающем его: lfs-test-server :
метаданные можно хранить только в репозитории git и большом файле в другом месте.

https://cloud.githubusercontent.com/assets/1319791/7051226/c4570828-ddf4-11e4-87eb-8fc165e5ece4.gif


3
lfs-test-serverобъявлен не для производственного использования. На самом деле, я работаю на производственном сервере LFS ( github.com/artemkin/git-lfs-server ). Он находится в стадии разработки, но уже исправен, и мы тестируем его на месте.
Стас

Можете ли вы проверить предыдущие версии такого двоичного файла, используя git lfs?
Мукахо

1
@mucaho Вы должны: синтаксис git checkout не изменился, и сценарий lfs smudge по-прежнему должен вызываться.
VonC

31

Взгляните на git bup, который является расширением Git для разумного хранения больших двоичных файлов в репозитории Git.

Вы хотели бы иметь его в качестве подмодуля, но вам не придется беспокоиться о том, что хранилище будет трудно обрабатывать. Один из примеров их использования - хранение образов виртуальных машин в Git.

На самом деле я не видел лучшей степени сжатия, но в моих репозиториях нет действительно больших двоичных файлов.

Ваш пробег может варьироваться.


3
bup обеспечивает хранение (внутреннее использование архивов четности для избыточности и git для сжатия, дедупликации и истории), но не расширяет git. git- annex - это расширение git, предоставляющее бэкэнд хранилища bup .
Тобу

@Tobu, когда я это опубликовал, git-приложение еще не существовало (в основных выпусках)
сэх

2
bup определенно интересен для управления большими файлами. Я хотел указать на разницу в пользовательском интерфейсе: вы используете команды bup вне контекста репозитория, а git - это деталь реализации.
Тобу

27

Вы также можете использовать мерзавец . Мне нравится, что это зависит только от стокового Python и rsync. Он также поддерживает обычный рабочий процесс Git со следующими понятными командами:

git fat init
git fat push
git fat pull

Кроме того, вам необходимо зарегистрировать файл .gitfat в своем хранилище и изменить свои .gitattributes, чтобы указать расширения файлов, которыми вы хотите git fatуправлять.

Вы добавляете двоичный файл, используя обычный git add, который в свою очередь вызывает git fatна основе ваших правил gitattributes.

Наконец, у него есть то преимущество, что место, где на самом деле хранятся ваши двоичные файлы, может быть общим для всех репозиториев и пользователей и поддерживает все, что rsyncделает.

ОБНОВЛЕНИЕ: не используйте git-fat, если вы используете мост Git-SVN. Это приведет к удалению двоичных файлов из вашего хранилища Subversion. Однако, если вы используете чистый Git-репозиторий, он прекрасно работает.


26

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

У меня была очень похожая проблема несколько месяцев назад: ~ 21 ГБ MP3-файлов, неклассифицированных (плохие имена, плохие id3, не знаю, нравится ли мне этот MP3-файл или нет ...) и реплицированных на трех компьютерах.

Я использовал внешний жесткий диск с основным репозиторием Git и клонировал его на каждый компьютер. Затем я начал классифицировать их обычным способом (толкание, вытягивание, объединение ... удаление и переименование много раз).

В итоге у меня было всего ~ 6 ГБ файлов MP3 и ~ 83 ГБ в каталоге .git. Я использовал git-write-treeи git-commit-treeдля создания нового коммита, без предков коммитов, и начал новую ветку, указывающую на этот коммит. «Журнал Git» для этой ветви показал только один коммит.

Затем я удалил старую ветку, сохранил только новую ветку, удалил ref-logs и запустил «git prune»: после этого мои папки .git весили всего ~ 6 ГБ ...

Вы можете время от времени «очищать» огромный репозиторий одним и тем же способом: ваш «мерзавец» будет быстрее.


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

1
Будет ли это так же, как просто: rm -f .git; git init; мерзавец добавить. ; git commit -m "Храни историю".
Пэт Нотц

1
Да, так же, только в моем случае mp3. Но иногда вы не хотите трогать свои ветви и теги (без уменьшения пространства в общедоступных репозиториях), но вы хотите ускорить «git clone / fetch / pull» только для ветви (меньше места для выделенных для этого отраслевые репозитории).
Даниэль Фанжул

13

Решение, которое я хотел бы предложить, основано на бесхозных ветвях и небольшом злоупотреблении механизмом тегов, далее именуемым * Бинарное хранилище бесхозных тегов (OTABS).

TL; DR 12-01-2017 Если вы можете использовать GFS от Github или какой-либо другой третьей стороны, во что бы то ни стало, вам следует. Если не можете, тогда читайте дальше. Имейте в виду, это решение является взломом и должно рассматриваться как таковое.

Желательные свойства ОТАБС

  • это чисто решение git and git only - оно выполняет свою работу без какого-либо стороннего программного обеспечения (например, git-annex) или сторонней инфраструктуры (например, LFS github).
  • он хранит двоичные файлы эффективно , т.е. не раздувание истории вашего репозитория.
  • git pullи git fetch, в том числе git fetch --all, по-прежнему эффективны по пропускной способности , то есть не все большие двоичные файлы извлекаются из удаленного по умолчанию.
  • это работает на Windows .
  • он хранит все в одном репозитории git .
  • это позволяет удалять устаревшие двоичные файлы (в отличие от bup).

Нежелательные свойства ОТАБС

  • это делает git cloneпотенциально неэффективным (но не обязательно, в зависимости от вашего использования). При развертывании этого решения вам, возможно, придется посоветовать коллегам использовать git clone -b master --single-branch <url>вместо git clone. Это происходит потому, что git clone по умолчанию буквально клонирует весь репозиторий, включая вещи, на которые вы обычно не хотите тратить свою пропускную способность, например нефиксированные коммиты. Взято из SO 4811434 .
  • это делает git fetch <remote> --tagsпропускную способность неэффективной, но не обязательно неэффективной для хранения. Вы всегда можете посоветовать своим коллегам не использовать его.
  • вам придется периодически использовать git gcхитрость для очистки вашего хранилища от любых файлов, которые вам больше не нужны.
  • это не так эффективно, как bup или git-bigfiles . Но это соответственно больше подходит для того, что вы пытаетесь сделать, и больше готово. Вы, вероятно, столкнетесь с проблемами с сотнями тысяч небольших файлов или с файлами размером в гигабайты, но читайте дальше для обходных путей.

Добавление бинарных файлов

Прежде чем начать, убедитесь, что вы зафиксировали все свои изменения, ваше рабочее дерево обновлено, а индекс не содержит незафиксированных изменений. Это может быть хорошей идеей - перенести все ваши локальные филиалы на удаленный компьютер (github и т. Д.) На случай, если произойдет какое-либо бедствие.

  1. Создать новую сиротскую ветку. git checkout --orphan binaryStuffсделает свое дело. Это создает ветку, которая полностью отключена от любой другой ветви, и первый коммит, который вы сделаете в этой ветке, не будет иметь родителя, что сделает его корневым.
  2. Очистите свой индекс, используя git rm --cached * .gitignore.
  3. Сделайте глубокий вдох и удалите все рабочее дерево, используя rm -fr * .gitignore. Внутренний .gitкаталог останется нетронутым, потому что *подстановочный знак не соответствует ему.
  4. Скопируйте в свой VeryBigBinary.exe или в свой каталог VeryHeavyDirectory /.
  5. Добавьте это && зафиксируйте это.
  6. Теперь это становится сложнее - если вы вставите его в удаленную ветвь как ветвь, все ваши разработчики загрузят его в следующий раз, когда они вызовут git fetchзасорение своего соединения. Вы можете избежать этого, нажав метку вместо ветки. Это все еще может повлиять на пропускную способность вашего коллеги и хранилище файловой системы, если они имеют привычку печатать git fetch <remote> --tags, но читайте дальше, чтобы обойти это. Идти вперед иgit tag 1.0.0bin
  7. Нажмите свой тег сироты git push <remote> 1.0.0bin.
  8. Точно так же, что вы никогда не нажмете свою бинарную ветку случайно, вы можете удалить ее git branch -D binaryStuff. Ваш коммит не будет помечен для сборки мусора, потому что на него 1.0.0binдостаточно пустого тега, указывающего на него .

Проверка двоичного файла

  1. Как я (или мои коллеги) извлекаю VeryBigBinary.exe в текущее рабочее дерево? Если ваша текущая рабочая ветка, например, master, вы можете просто git checkout 1.0.0bin -- VeryBigBinary.exe.
  2. Это не удастся, если у вас нет 1.0.0binзагруженного тега-сироты , в этом случае вам придется сделать это git fetch <remote> 1.0.0binзаранее.
  3. Вы можете добавить его к VeryBigBinary.exeсвоему мастеру .gitignore, чтобы никто в вашей команде не загрязнил основную историю проекта двоичным файлом.

Полное удаление двоичного файла

Если вы решите полностью удалить VeryBigBinary.exe из локального хранилища, удаленного хранилища и хранилищ вашего коллеги, вы можете просто:

  1. Удалить потерянный тег на пульте git push <remote> :refs/tags/1.0.0bin
  2. Удалить потерянный тег локально (удаляет все остальные теги, на которые нет ссылок) git tag -l | xargs git tag -d && git fetch --tags. Взято из SO 1841341 с небольшой модификацией.
  3. Используйте хитрость git gc, чтобы удалить ваш теперь не имеющий ссылки коммит локально. git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc "$@", Это также удалит все другие не связанные ссылки. Взято из SO 1904860
  4. Если возможно, повторите трюк с git gc на пульте. Это возможно, если вы самостоятельно размещаете свой репозиторий, и это может быть невозможно с некоторыми провайдерами git, такими как github или в некоторых корпоративных средах. Если вы пользуетесь хостингом у провайдера, который не предоставляет доступ по ssh к удаленному, просто оставьте его. Вполне возможно, что инфраструктура вашего провайдера очистит вашу ссылку без привязки в свое приятное время. Если вы находитесь в корпоративной среде, вы можете посоветовать своим ИТ-специалистам запускать мусорное задание cron, собирая ваш пульт один раз в неделю или около того. Независимо от того, влияют они или нет, это не окажет никакого влияния на вашу команду с точки зрения пропускной способности и хранилища, если вы советуете своим коллегам всегда git clone -b master --single-branch <url>вместо git clone.
  5. Всем вашим коллегам, которые хотят избавиться от устаревших тегов-сирот, нужно только применить шаги 2-3.
  6. Затем вы можете повторить шаги 1-8 из Добавление двоичных файлов, чтобы создать новый потерянный тег 2.0.0bin. Если вы беспокоитесь о том, что ваши коллеги печатают, git fetch <remote> --tagsвы можете назвать это снова 1.0.0bin. Это будет гарантировать, что в следующий раз, когда они извлекут все теги, старые 1.0.0binне будут ссылаться и помечены для последующей сборки мусора (с помощью шага 3). Когда вы пытаетесь перезаписать тег на пульте, вы должны использовать -fэто так:git push -f <remote> <tagname>

Послесловие

  • OTABS не касается вашего мастера или любых других исходных кодов / веток разработки. Хеши коммитов, вся история и небольшой размер этих веток не затрагиваются. Если вы уже раздули свою историю исходного кода с помощью двоичных файлов, вам придется очистить ее как отдельную часть работы. Этот скрипт может быть полезен.

  • Подтвердили работу на Windows с помощью git-bash.

  • Рекомендуется применять набор стандартных трюков, чтобы сделать хранение бинарных файлов более эффективным. Частое выполнение git gc(без каких-либо дополнительных аргументов) заставляет git оптимизировать базовое хранилище ваших файлов с помощью двоичных дельт. Однако, если ваши файлы вряд ли останутся похожими на коммит, вы можете вообще отключить бинарные дельты. Кроме того, поскольку нет смысла сжимать уже сжатые или зашифрованные файлы, такие как .zip, .jpg или .crypt, git позволяет отключить сжатие основного хранилища. К сожалению, это параметр «все или ничего», влияющий и на ваш исходный код.

  • Возможно, вы захотите написать сценарий части OTABS, чтобы обеспечить более быстрое использование. В частности, сценарии 2-3 из « Полное удаление двоичных файлов в updateловушку git» могут дать убедительную, но, возможно, опасную семантику для git fetch («извлекать и удалять все, что устарело»).

  • Возможно, вы захотите пропустить шаг 4 « Полное удаление двоичных файлов», чтобы сохранить полную историю всех двоичных изменений на удаленном компьютере за счет раздувания центрального хранилища. Локальные хранилища со временем останутся сухими.

  • В мире Java можно комбинировать это решение с maven --offlineсозданием воспроизводимой автономной сборки, хранящейся полностью в вашем контроле версий (это проще с maven, чем с gradle). В мире Голанга возможно использовать это решение для управления GOPATH вместо go get. В мире Python это можно комбинировать с virtualenv для создания автономной среды разработки, не полагаясь на серверы PyPi для каждой сборки с нуля.

  • Если двоичные файлы меняются очень часто, как строят артефакты, это может быть хорошей идеей для сценария решения , которое хранит 5 последних версии артефактов в тегах бесхозных monday_bin, tuesday_bin, ..., friday_bin, а также сиротые теги для каждого выпуска 1.7.8bin 2.0.0binи т. д. Вы можете weekday_binежедневно поворачивать и удалять старые двоичные файлы. Таким образом, вы получаете лучшее из двух миров: вы сохраняете всю историю вашего исходного кода, но только соответствующую историю ваших двоичных зависимостей. Также очень легко получить двоичные файлы для данного тега, не получая весь исходный код со всей его историей: это git init && git remote add <name> <url> && git fetch <name> <tag>следует сделать за вас.


«Приходится периодически пользоваться git gc», - перестал читать тут же. Зачем кому-то отказываться от своего последнего ремня безопасности в пользу какого-то взлома?
user1643723 16.09.16

@ user1643723 git gcнебезопасен для запуска. Все ваши коммиты будут по умолчанию храниться
Адам Куркевич

Спасибо за подробную рецензию. Я хотел попробовать это как способ хранения некоторых бинарных зависимостей в моем репозитории GitHub таким образом, чтобы они не загружались по умолчанию, когда кто-то клонировал репо, но могли быть загружены вручную и обновлять локальное репо. Тем не менее, я получил сообщение об ошибке на этом шаге: git push <remote> 1.0.0bin- remote: error: GH001: Large files detected. You may want to try Git Large File Storage. Похоже, что GitHub больше не поддерживает это? Размер рассматриваемого двоичного файла составлял 100 МБ.
user5359531

1
Если честно, если вам разрешено использовать github для своей работы, что мешает вам использовать LFS? Ребята из github усердно работали над созданием этого продукта, и они даже размещают его для вас, и их инфраструктура оптимизирована для его использования. Этот хак предназначен для ситуаций, когда вы действительно не можете использовать LFS или других сторонних разработчиков, и вам нужен чистый мерзавец.
Адам Куркевич

Я также обновил ответ, чтобы было более понятно, насколько хакерским является это решение на самом деле.
Адам Куркевич

13

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

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


13
И отдельные репо не сделают время оформления заказа короче, так как вам все равно придется проверить оба репо!
Эмиль Сит

@EmilSit отдельного репо может сделать покупку намного короче, если вы будете постоянно очищать историю «бинарного репо». Более того, разработчикам не придется каждый раз проверять оба репо .
FabienAndre

Почему бы просто не заставить скрипт сборки основного модуля извлекать двоичные файлы из второго репо, извлекая их по одному (как здесь: stackoverflow.com/questions/1125476/… ).
akauppi

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

9

SVN, кажется, обрабатывает двоичные дельты более эффективно, чем Git.

Я должен был выбрать систему управления версиями для документации (файлы JPEG, файлы PDF и файлы .odt). Я только что протестировал добавление файла JPEG и поворот его на 90 градусов четыре раза (чтобы проверить эффективность двоичных дельт). Репозиторий Git вырос на 400%. Репозиторий SVN вырос только на 11%.

Похоже, что SVN намного эффективнее с двоичными файлами.

Поэтому я выбрал Git для исходного кода и SVN для бинарных файлов, таких как документация.


33
Вам просто нужно было запустить "git gc" (переупаковка и сборка мусора) после добавления этих 4 файлов. Git не сразу сжимает весь добавленный контент, так что вы будете иметь сжатие группы файлов (что более эффективно с точки зрения размера) и не будете замедлять раздельное сжатие каждого добавленного объекта. Но даже без «git gc», git в любом случае сделал бы для вас сжатие (после того, как заметил, что накопилось достаточно неупакованных объектов).
соловей

24
@jpierson Я создал пустой репозиторий git и добавил (и зафиксировал) полностью белое bmp-изображение размером 41 МБ, в результате чего был создан общий репозиторий git размером 328 КБ. После git gcтого, как общий размер хранилища git был уменьшен до 184KB. Затем я изменил один пиксель с белого на черный и зафиксировал это изменение, общий размер репозитория git увеличился до 388 КБ, а после git gcэтого размер общего репозитория git был уменьшен до 184 КБ. Это показывает, что git довольно хорош в сжатии и поиске дельт двоичных файлов.
Tader

6
@jpierson Sidenote: я только что прокомментировал двоичные дельты. Git съест всю вашу память и поменяется местами, если он управляет репозиториями с большими (размером ГБ) файлами. Для этого используйте git-annex (уже упоминалось в другом ответе) ...
Tader

12
@JanDvorak - никто не упомянул об этом, потому что это полностью не соответствует действительности. Копии Subversion стоят дешево - svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html - примерно в середине страницы.
Йорис Тиммерманс

12
@Tader: твой тест плохой. То, что вы называете двоичным файлом, на самом деле (с точки зрения git) больше похоже на текстовый файл - битовый поток выровнен по байту, и существуют важные локализованные разности, которые необходимо сделать; в конце концов, изменение одного пикселя в основном эквивалентно изменению одного символа в текстовом файле (и кто сейчас использует несжатые растровые изображения?) Попробуйте тот же эксперимент с небольшим видео, сжатым изображением, виртуальной машиной, zip-файлом или чем-то еще - и вы найдете этот мерзавец не справляется эффективно с дельтой; на самом деле это принципиально невозможно с несжимаемыми данными.
Имон Нербонн

4

git clone --filter из Git 2.19 + мелкие клоны

Эта новая опция может в конечном итоге стать окончательным решением проблемы бинарных файлов, если разработчики Git и GitHub сделают ее достаточно удобной для пользователя (что, вероятно, до сих пор не достигли, например, для подмодулей ).

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

При этом мы могли бы сначала сделать неглубокое клонирование, а затем автоматизировать, какие двоичные объекты следует выбирать с помощью системы сборки для каждого типа сборки.

Существует даже уже --filter=blob:limit<size> который позволяет ограничить максимальный размер капли для выборки.

Я представил минимальный подробный пример того, как выглядит эта функция: Как мне клонировать только подкаталог репозитория Git?


2

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

Лично я столкнулся с ошибками синхронизации с Git с некоторыми из моих облачных хостов, когда двоичные данные моих веб-приложений оказались выше отметки 3 ГБ . В то время я рассматривал BFT Repo Cleaner , но это было похоже на взлом. С тех пор я начал просто хранить файлы вне сферы действия Git, вместо этого используя специальные инструменты, такие как Amazon S3, для управления файлами, управления версиями и резервного копирования.

У кого-нибудь есть опыт работы с несколькими Git-репозиториями и управления ими в одном проекте?

Да. Гуго темы в основном управляются таким образом. Это немного круто, но это делает работу.


Мое предложение состоит в том, чтобы выбрать правильный инструмент для работы . Если это для компании, и вы управляете своей кодовой линией на GitHub, заплатите деньги и используйте Git-LFS. В противном случае вы могли бы изучить более креативные варианты, такие как децентрализованное, зашифрованное хранилище файлов с помощью блокчейна .

Дополнительные опции для рассмотрения включают Minio и s3cmd .


0

Посмотрите на camlistore . На самом деле он не основан на Git, но я считаю его более подходящим для того, что вы должны делать.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.