Git lfs как пользоваться

Управление и хранение больших файлов в Git

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

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

Какие файлы следует хранить в Git?

Зависимости, не зависящие от исходного кода

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

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

Не фиксировать выходные данные

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

Хранение небольших, редко обновляемых двоичных источников в Git

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

Даже небольшие двоичные файлы могут вызвать проблемы при частом обновлении. Сто изменений в двоичном файле размером 100 КБ использует столько же памяти, сколько 10 изменений в двоичном файле размером 1 МБ, а из-за частоты обновлений в меньшем двоичном файле снижается производительность ветвления чаще, чем большой двоичный файл.

Не фиксируйте большие, часто обновляемые двоичные ресурсы

Git будет управлять одной main версией файла, а затем хранить только отличия от этой версии в процессе, известном как делефикация. Deltification и сжатие файлов позволяют Git хранить весь журнал кода в локальном репозитории. Большие двоичные файлы обычно полностью меняются между версиями и часто уже сжаты, что затрудняет управление этими файлами для Git, так как разница между версиями очень велика. Git должен хранить все содержимое каждой версии файла и испытывать трудности с экономией места за счет делефикации и сжатия. Хранение полных версий файлов этих файлов приводит к увеличению размера репозитория с течением времени, снижению производительности ветвления, увеличению времени клонирования и увеличению требований к хранилищу.

Стратегии работы с большими двоичными исходными файлами

• Не фиксируйте сжатые архивы данных. Лучше распаковывать файлы и фиксировать доступные источники, позволяя Git обрабатывать сжатие данных в репозитории.
• Избегайте фиксации скомпилированного кода и других двоичных зависимостей. Зафиксируйте источник и создайте зависимости или используйте решение для управления пакетами до версии и предоставьте эти файлы в систему.
• Храните конфигурацию и другие структурированные данные в различаемых форматах обычного текста, таких как JSON.

Использовать хранилище больших файлов Git (LFS).

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

Преимущества

Преимущество Git LFS заключается в том, что ваша команда может использовать знакомый комплексный рабочий процесс Git независимо от того, какие файлы создает ваша команда. Файлы LFS могут быть настолько большими, насколько нужно. Кроме того, начиная с версии 2.0, Git LFS поддерживает блокировку файлов, чтобы помочь вашей команде работать с большими ресурсами без возможности сравнения, такими как видео, звуки и игровые карты.

Git LFS полностью поддерживается и бесплатно в Azure DevOps Services. Чтобы использовать LFS с Visual Studio, вам потребуется по крайней мере Visual Studio 2015 с обновлением 2. Просто выполните инструкции по установке клиента, настройте LFS отслеживание файлов в локальном репозитории, а затем отправьте изменения в Azure Repos.

Ограничения

Git LFS имеет некоторые недостатки, которые следует учитывать перед принятием:

1. Каждый клиент Git, используемый командой, должен установить клиент GIT LFS и ознакомиться с его конфигурацией отслеживания.
2. Если клиент Git LFS не установлен и не настроен правильно, двоичные файлы, зафиксированные с помощью Git LFS, не будут отображаться при клонировании репозитория. Git скачивает данные, описывающие большой файл (тот, что Git LFS фиксирует в репозитории), а не фактический двоичный файл. Фиксация больших двоичных файлов без установленного клиента Git LFS приведет к отправке двоичного файла в репозиторий.
3. Git не может объединить изменения из двух разных версий двоичного файла, даже если обе версии имеют общий родительский элемент. Если два пользователя работают над тем же файлом одновременно, они должны работать вместе, чтобы согласовать свои изменения и избежать перезаписи работы другого пользователя. Для этого Git LFS предоставляет возможность блокировки файлов. Пользователи по-прежнему должны заботиться о том, чтобы всегда извлекать последнюю копию двоичного актива перед началом работы.
4. Azure Repos сейчас не поддерживает использование SSH в репозиториях с отслеживаемыми файлами Git LFS.
5. Если пользователь перетаскивает двоичный файл через веб-интерфейс в репозиторий, настроенный для GIT LFS, двоичный файл будет зафиксирован в репозитории, а не указатели, которые будут зафиксированы с помощью клиента Git LFS.
6. Максимальный размер файла составляет 50 Гб.
7. Ограничение времени отправки одного файла составляет 1 час.

Формат файла

Файл, записанный в репозиторий для отслеживаемого файла Git LFS, будет содержать несколько строк с парой ключей и значений в каждой строке:

version https://git-lfs.github.com/spec/v1 oid a747cfbbef63fc0a3f5ffca332ae486ee7bf77c1d1b9b2de02e261ef97d085fe size 4923023 

URL-адрес GitHub, включенный для значения версии, определяет только тип файла указателя LFS и не является ссылкой на двоичный файл.

Известные проблемы

Если вы используете версию LFS ниже 2.4.0 с Azure DevOps Server или TFS, для проверки подлинности с помощью NTLM вместо Kerberos требуется дополнительный шаг настройки. Этот шаг больше не требуется в версии LFS 2.4.0, и мы настоятельно рекомендуем выполнить обновление.

Git LFS

Git Large File Storage ( LFS ) это расширение Git’а, предназначенное для версионирования больших файлов. Git LFS заменяет большие файлы (аудио, видео, наборы данных или графические файлы) текстовыми указателями внутри Git’а, в то время как само содержимое этих файлов сохраняется на удалённом сервере, таком как GitHub.com или GitHub Enterprise .

Для больших конфигураций 1С:Предприятия 8 хранение бинарных файлов внутри репозитория может приводить к чувствительным замедлениям. Поэтому желательно использовать Git LFS для хранения файлов конфигураций поставщиков, файлов макетов двоичных данных и картинок.

Мы рекомендуем использовать Git LFS в тех ситуациях, когда:

• объём хранилища конфигурации больше 300 Мб и количество версий больше 1 000, или
• объём хранилища конфигурации больше 100 Мб и в нем есть конфигурации поставщика.

Большинство серверов Git (например, GitLab , GitHub , BitBucket ) поддерживают Git LFS . Нужно только включить его использование для вашего проекта.

Однако на сервере 1С:ГитКонвертера и на локальных компьютерах разработчиков Git LFS нужно установить отдельно, до того, как будет выполнен первый коммит в локальном хранилище.

Установка и настройка Git LFS описана в документации 1С:ГитКонвертера в разделе Git LFS.

Как работает git lfs?

Не могу разобраться как работает git lfs. Нужно загрузить проект на github, но в нем много картинок и через git push не
получается.
Что я сделал:
1. Установил расширение отсюда https://github.com/git-lfs/git-lfs/releases
2. Прописал в консоли
git lfs track «*.jpg»
git add —all
git commit -m «first commit»
git push origin master
и вот что у меня в итоге выводится в консоли:
Locking support detected on remote «origin». Consider enabling it with:
$ git config ‘lfs.https://github.com/seriiserii825/wpCleanMag.git/in. ‘ true
Git LFS: (0 of 0 files, 20 skipped) 0 B / 0 B, 951.71 KB skipped Co
unting objects: 155, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (149/149), done.
Writing objects: 100% (155/155), 154.55 MiB | 6.86 MiB/s, done.
Total 155 (delta 24), reused 0 (delta 0)
remote: Resolving deltas: 100% (24/24), done.
remote: error: GH001: Large files detected. You may want to try Git Large File Storage — https://git-lfs.github.com.
remote: error: Trace: a9d71848e629b3876e939a108eb54cb0
remote: error: See git.io/iEPt8g for more information.
remote: error: File img/RazerCortexSetup_8.0.104.420.exe is 151.63 MB; this exceeds GitHub’s file size limit of 100.00 MB
To https://github.com/seriiserii825/wpCleanMag.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to ‘https://github.com/seriiserii825/wpCleanMag.git’

Почему Git LFS: (0 of 0 files, 20 skipped) 0 B / 0 B, 951.71 KB skipped Co ?

Для меня не совсем понятно, как вся эта система работает? Прошу помощи.

• Вопрос задан более трёх лет назад
• 12041 просмотр

Комментировать
Решения вопроса 1

> Прошу помощи
помогаю разглядеть суть. дешево. оптовикам скидки

remote: error: File img/RazerCortexSetup_8.0.104.420.exe is 151.63 MB; this exceeds GitHub’s file size limit of 100.00 MB

Ответ написан более трёх лет назад
Нравится 3 7 комментариев

»’
It’s the ideal solution for pushing files to GitHub that are larger than 100 MB.
»’

»’
If you’ve set up Git LFS, and you have an existing file in your repository that needs to be tracked in Git LFS, you need to first remove it from your repository.
»’

Сведения о службе хранилища больших файлов Git и GitHub Desktop

GitHub Desktop включает Хранилище больших файлов Git для управления большими файлами.

При установке GitHub Desktop также устанавливается Хранилище больших файлов Git (Git LFS). Git LFS позволяет отправлять файлы в GitHub сверх обычного ограничения 100 МиБ. Дополнительные сведения о Git LFSсм. в разделе «Сведения о хранилище больших файлов Git Large File Storage».

Чтобы использовать Git LFS с GitHub Desktop, необходимо настроить Git LFS с помощью командной строки. Дополнительные сведения см. в разделе «AUTOTITLE».

Настроив Git LFS для отслеживания файлов в репозитории, можно легко получить доступ к большим файлам и управлять ими с помощью GitHub Desktop как и любым другим файлом в репозитории.

Дополнительные материалы

• «Управление большими файлами»
• «Управление большими файлами»