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 Large File Storage
Если вы настроили Git LFS и у вас есть файл в репозитории, который необходимо отслеживать в Git LFS, необходимо сначала удалить его из репозитория.
После установки Git LFS и настройки отслеживания Git LFS можно переместить файлы из обычного отслеживания Git в Git LFS. Дополнительные сведения см. в разделе «[AUTOTITLE» и «Установка хранилища больших файлов Git](/repositories/working-with-files/managing-large-files/configuring-git-large-file-storage)».
Если имеются ссылки на файлы Git LFS, которые не были успешно отправлены, появится сообщение об ошибке. Дополнительные сведения см. в разделе «AUTOTITLE».
Совет. Если появляется сообщение об ошибке «Превышен предельный размер файла Git LFS, равный 100 МиБ» при попытке отправить файлы в Git, можно использовать git lfs migrate вместо filter-repo или BFG Repo Cleaner для перемещения большого файла в Хранилище больших файлов Git. Дополнительные сведения о команде git lfs migrate см. в объявлении о выпуске Git LFS 2.2.0.
- Удалите файл из журнала Git репозитория с помощью команды filter-repo или BFG Repo-Cleaner. Подробные сведения об использовании см. в разделе «Удаление конфиденциальных данных из репозитория».
- Настройте отслеживание файла и отправьте его в Git LFS. Дополнительные сведения об этой процедуре см. в разделе «Настройка Git Large File Storage».
Дополнительные материалы
- «Сведения о хранилище больших файлов Git Large File Storage»
- «Совместная работа с помощью Git Large File Storage»
- «Установка хранилища больших файлов Git»
Как работает 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 ?
Для меня не совсем понятно, как вся эта система работает? Прошу помощи.
- Вопрос задан более трёх лет назад
- 11989 просмотров
Комментировать
Решения вопроса 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 LFS влияет на опыт ведения документации рядом с кодом
Подход к ведению документации рядом с кодом используется в Альфа-Банке на протяжении нескольких лет. Он хорошо подходит для документирования API и сервисов, не требующего примеров пользовательского интерфейса. Однако с документацией на мобильные и веб-фронты ситуация немного сложнее.
В статье обозначу проблему, связанную с ведением фронтовой документации рядом с кодом, и приведу одно из решений на базе Git LFS. Затем поделюсь результатами двух пилотов, проведённых в Банке во втором квартале 2023. Их результаты помогут оценить влияние Git LFS на опыт ведения фронтовой документации рядом с кодом. Статья подойдёт всем, кто занимается подготовкой технической документации на программные продукты.
Особенность фронтовой документации — это необходимость соблюдения требования функционального сопровождения к наличию в ней примеров пользовательского интерфейса. Они необходимы, чтобы лучше понимать то, что видит конечный пользователь, его действия и результат, к которым эти действия привели.
Бинарные файлы изображений с примерами пользовательского интерфейса обычно весят больше, чем текстовые файлы с исходниками кода или документации.
Если размер одного скриншота экрана в формате .png весит 500 Кб, а всего в документе 50 изображений, то всего лишь одна версия документа будет весить 25 Мб. Для сравнения, вес репозитория с кодом главной страницы интернет-банка, куда многие продукты стремятся встроить свой функционал, со всей историей коммитов, начиная с 2016 года составляет около 30 Кб.
Добавление файлов изображений в репозитории приводит к их раздуванию, а следовательно, к возрастанию нагрузки на сеть при клонировании, увеличению времени сборки, расходованию дополнительного дискового пространства.
Четыре года назад мы с коллегами пытались решить данную проблему за счёт автоматической генерации документации, в том числе примеров пользовательского интерфейса, из автотестов. Решение было представлено на AnalyzeIT MeetUp #2, однако не получило развития в связи с ограничениями на доработку под требования функционального сопровождения и стандарты ведения документации Банка.
В прошлом году было предложено альтернативное решение. Для хранения файлов изображений предлагалось использовать хранилище Artifactory, взаимодействие с которым было бы реализовано средствами Git LFS. Решение было опробовано на моей локальной машине и описано в статье Как мы ведём документацию рядом с кодом.
В этом году появилась возможность реализовать описанное решение в Банке, но с небольшой модификацией — хранилище LFS предоставляется корпоративным Bitbucket. В качестве CI/CD используется собственная система на базе Jenkins.
Более подробную информацию о том, что получилось, можно узнать из доклада Игоря Савинова, представленного на недавно прошедшем Alfa Analyze IT Meetup.
Во втором квартале 2023 мы запустили пилот данного решения на нескольких командах. Параллельно на других командах проводился пилот похожего решения, но без Git LFS, предполагающего размещение файлов изображений прямо в репозитории. Таким образом, у нас появилась возможность оценить влияние Git LFS на опыт ведения фронтовой документации.
В конце квартала мы подготовили анкету для сбора обратной связи с участников пилотов, среди вопросов которой, были следующие:
- Удобно ли вести документацию?
- Удобно ли читать документацию?
- Удобно ли искать документацию?
- Насколько трудозатратно вести документацию по сравнению с Confluence?
Со стороны Решения А (без Git LFS) обратную связь оставили 5 человек, со стороны Решения В (с Git LFS) — 7. Далее результаты опроса.
Удобно ли вести документацию?
В обоих пилотах респонденты разделились пополам. Одна половина находит решение удобным для ведения фронтовой документации, другая так не считает.
В качестве преимуществ участники пилотов отметили процесс ревью документации и возможность отслеживания истории изменений. Вот несколько мнений на этот счёт.
«Удобный процесс ревью (добавление аппруверов, комментарии, отображение диффов)»
«Удобно работать с историей изменения документации»
«Более структурированное хранение, возможность отследить кто и что конкретно менял»
В качестве недостатков были указаны отсутствие WYSIWYG-редактора, возможности вставки изображений из буфера и ограниченные возможности по форматированию документов:
«Тяжело писать именно фронтовую документацию в asciidoc из-за отсутствия wysiwyg-редактора»
«Самое неудобное — это добавление картинок, их надо скачать, пронумеровать, переместить в IDEA»
«В Конфлюенсе больше возможностей для красивого ведения документации, их проще реализовать»
Удобно ли читать документацию?
Как и в вопросе про ведение документации, мнения разделились. Для одной половины решение удобно, для другой — нет.
По мнению участников пилотов, итоговой версией документации могут пользоваться не только эксперты функционального сопровождения, но и представители бизнеса:
«Документацию могут использовать как саппорт, так и бизнес»
Недостаток увидели в расположении примеров пользовательского интерфейса, отдельном от текстового описания, вызванного отсутствием возможности увеличения изображения в итоговой версии документа.
«Тяжело читать готовую документацию, так как макеты располагаются после таблиц»
Удобно ли искать документацию?
Участники обоих пилотов в большинстве своём считают решение удобным для поиска документации.
В качестве комментариев к ответам были указаны следующие:
«Не нужно искать документацию по фронту по всем пространствам, найти репозиторий всегда проще»
«Более понятный поиск нужной документации»
Насколько трудозатратно вести документацию по сравнению с Confluence?
Большинство участников пилотов считают решение более трудозатратными. Причём решение без Git LFS оценивается большинством как сильно более трудозатратное.
Основная причина, по-видимому, это недостаток знаний и опыта работы респондентов с используемым языком текстовой разметки. Один из полученных комментариев это достаточно хорошо иллюстрирует:
«Если плохо знаешь asciidoc, то на внесение изменений уходит большое количество времени»
Что в итоге?
Анализ полученной от участников пилотов обратной связи позволяет сделать вывод, что использование Git LFS не влияет на опыт ведения фронтовой документации.
Данная надстройка функционирует незаметно для члена команды и не меняет флоу его работы с репозиторием. Git LFS позволяет избежать раздувания репозитория, поэтому решение с его использованием (Решение В) может стать подходящим вариантом для ведения документации на мобильные и веб-фронты.
Вместе с этим отношение респондентов к ведению фронтовой документации рядом с кодом неоднозначное.
Половина из них считает пилотные решения неудобными для ведения и чтения документации. Плюс их использование более трудозатратно, если сравнивать с Confluence.
Поэтому прежде чем принять решение о масштабном внедрении рассмотренного решения нужно ещё раз взвесить все «за» и «против», а также попытаться устранить недостатки, подсвеченные участниками пилотов.
В наших командах ведением технической документации на программные продукты занимаются системные аналитики. Часто они мне задают вопрос, зачем вести документацию рядом с кодом. Ответ на этот вопрос не является темой настоящей статьи. Однако тем, кому интересно разобраться, рекомендую ознакомиться с материалами:
- Грановская Ю., Маркелов И. Версионирование требований — применение аналитиками классических практик разработчиков
- Новикова Л., Валеев К., Факторович С., Волынкин Н., Поташников Н., Белянина А. DocOps в работе системного аналитика
- Поташников Н., Лобзов А., Зингер Е., Гришанов С., Волынкин Н. [Flow live] Docs as code для аналитика
- Как мы ведём требования к ПО: формализация
- Как мы ведём документацию рядом с кодом
- Разбираюсь в мок-серверах и пишу свой
- Как мы управляем техническим долгом аналитики
- Про IT рекрутмент и людей
- Как оптимизировать процесс привлечения клиентов B2B с помощью методов Продвинутой Аналитики
- Как перестать волноваться и полюбить хакатоны
Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.