Керування великими бінарними файлами за допомогою Git

Я шукаю думки, як обробляти великі двійкові файли, від яких залежить мій вихідний код (веб-додаток). Зараз ми обговорюємо декілька альтернатив:

1. Скопіюйте двійкові файли вручну.
   • Pro: Не впевнений.
   • Контраст: Я категорично проти цього, оскільки це збільшує ймовірність помилок під час створення нового веб-сайту / міграції старого. Створює ще одне перешкоду, яке потрібно зробити.
2. Керуйте ними всіма за допомогою Git .
   • Pro: видаляє можливість "забути" скопіювати важливий файл
   • Контраст: розкриває сховище і зменшується гнучкість управління базою коду, а каси, клони тощо потребують досить тривалого часу.
3. Окремі сховища.
   • Про: Перевірка / клонування вихідного коду відбувається швидко, як ніколи, і зображення належним чином архівуються у власному сховищі.
   • Контраст: Вилучає простоту створення одного і єдиного сховища Git у проекті. Це, безумовно, вносить деякі інші речі, про які я не думав.

Які ваші переживання / думки щодо цього?

Також: Хтось має досвід роботи з декількома сховищами Git та керуванням ними в одному проекті?

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

Якщо програма не працюватиме без файлів, здається, розділення їх на окремий репо - це погана ідея. У нас є великі тестові набори, які ми розбиваємо на окремий репо, але це справді "допоміжні" файли.

Однак ви, можливо, зможете керувати файлами в окремому репо-файлі, а потім скористатися, git-submoduleщоб втягнути їх у ваш проект здоровим чином. Отже, ви б все ще мали повну історію всього свого джерела, але, як я розумію, у вас буде лише одна відповідна редакція підмодуля ваших зображень. git-submoduleЗасіб має допомогти вам зберегти правильну версію коду відповідно до правильною версією зображення.

Ось хороший вступ до підмодулів з Git Book.

Нещодавно я відкрив git-annex, який мені здається дивним. Він був розроблений для ефективного управління великими файлами. Я використовую його для колекцій фото / музики (тощо). Розробка git-annex дуже активна. Вміст файлів можна видалити з сховища 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 repo, а у великому файлі - в іншому місці.

Погляньте на git bup, який є розширенням Git для розумного зберігання великих бінарних файлів у сховищі Git.

Ви хочете мати його як підмодуль, але вам не доведеться турбуватися про те, що сховище важко обробляється. Один із випадків використання зразків - це зберігання зображень VM в Git.

Насправді я не бачив кращих показників стиснення, але мої сховища не мають в них дійсно великих двійкових файлів.

Ваш пробіг може відрізнятися.

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

git fat init
git fat push
git fat pull

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

Ви додаєте двійковий код за допомогою звичайного git add, який, у свою чергу, викликає git fatна основі ваших правил gitattributes.

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

ОНОВЛЕННЯ: Не використовуйте git-жир, якщо ви використовуєте міст Git-SVN. Це в кінцевому підсумку видалить двійкові файли з вашого сховища Subversion. Однак якщо ви використовуєте чистий сховище Git, воно працює чудово.

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

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

Я використовував зовнішній жорсткий диск з основним сховищем Git і клонував його до кожного комп'ютера. Потім я почав класифікувати їх звичним способом (штовхати, тягнути, зливати ... видалення та перейменування багато разів).

Зрештою, у мене було лише ~ 6 ГБ MP3-файлів та ~ 83 ГБ у каталозі .git. Я використовував git-write-treeі git-commit-treeдля створення нового комітету, без предків, і розпочав нову гілку, яка вказує на це. "Журнал git" для цієї гілки показав лише один фіксатор.

Потім я видалив стару гілку, зберігав лише нову гілку, видалив журнали ref-журналів і запустив "git prune": після цього мої папки .git важили лише ~ 6 ГБ ...

Ви можете час від часу «очищати» величезний сховище однаково: Ваш «git clone» буде швидше.

Я б хотів запропонувати рішення, засноване на осиротілих гілках та незначному зловживанні механізмом тегів, відтепер його називають * Двоєчне зберігання сиротинних тегів (OTABS)

TL; DR 12-01-2017 Якщо ви можете використовувати LFS github або будь-яку іншу сторону, будь-якими силами. Якщо ви не можете, то читайте далі. Попереджуйте, що це рішення є хакерським, і його слід розглядати як таке.

Бажані властивості OTABS

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

Небажані властивості OTABS

• це робить git cloneпотенційно неефективним (але не обов'язково, залежно від використання). Якщо ви розгорнете це рішення, можливо, вам доведеться порадити колегам використовувати його git clone -b master --single-branch <url>замість git clone. Це пояснюється тим, що git-клон за замовчуванням буквально клонує весь сховище, включаючи речі, на які ви зазвичай не хочете витрачати свою пропускну здатність, як, наприклад, невикористані комісії. Взято з 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 у поточному робочому дереві? Якщо ваша робоча галузь, наприклад, майстер, ви можете просто 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 доступу до віддаленого, просто нехай це буде. Цілком можливо, що інфраструктура вашого постачальника очистить ваші нерозділені зобов’язання у власний солодкий час. Якщо ви знаходитесь у корпоративному середовищі, ви можете порадити своїм ІТ-інспекторам запускати сміттєві завдання, збираючи ваш пульт раз на тиждень. Незалежно від того, чи вони це роблять, чи ні, це не матиме жодного впливу на вашу команду з точки зору пропускної здатності та зберігання, якщо ви радите своїм колегам завжди 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). У світі Golang можливо, щоб на цьому рішенні можна було керувати, а не керувати своїм 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. В іншому випадку ви можете вивчити більш креативні варіанти, такі як децентралізоване, зашифроване зберігання файлів за допомогою blockchain .

Додаткові варіанти, які слід врахувати, включають Minio та s3cmd .

Погляньте на камлістор . Це насправді не на основі Git, але я вважаю, що це більше підходить для того, що вам потрібно зробити.