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

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

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

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

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

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

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

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

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

Недавно я обнаружил 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 .

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

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

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

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

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

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

Вы также можете использовать мерзавец . Мне нравится, что это зависит только от стокового 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-репозиторий, он прекрасно работает.

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

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

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

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

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

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

Решение, которое я хотел бы предложить, основано на бесхозных ветвях и небольшом злоупотреблении механизмом тегов, далее именуемым * Бинарное хранилище бесхозных тегов (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 cloneили git checkout, то вам следует серьезно подумать об использовании другого Git-репозитория (или, возможно, другого способа доступа к этим файлам).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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