Работа с большими файлами в репозитории Git

Сервисы Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

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

Выбор места хранения каждого файла

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

  • Сохраняйте исходные файлы, скрипты и текстовые файлы в Git.
  • Переместите зависимости и повторно используемые пакеты в Azure Artifacts для управления пакетами.
  • Используйте Git LFS для больших двоичных файлов, которые часто изменяются и плохо поддаются сравнению версий.
  • Удалите большие двоичные файлы из истории репозитория, если они уже добавлены в него и больше не должны там находиться. См. статью "Удалить большие файлы из репозитория".

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

Выбор подходящего варианта хранения для Git, управления пакетами и Git LFS

Используйте эту таблицу, чтобы выбрать оптимальный вариант.

Тип файла или сценарий Использование
Исходный код, скрипты и текстовые файлы Git
Зависимости и многократно используемые пакеты управление пакетами Azure Artifacts
Большие двоичные файлы, которые часто изменяются Git LFS (Git Large File Storage — поддержка хранения больших файлов в Git)
Azure DevOps Server Git LFS и Kerberos Ознакомьтесь с рекомендациями по Kerberos в этой статье и в статье, ссылка на которую приведена в конце.

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

Большие двоичные файлы не подходят для обычного хранилища Git, так как:

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

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

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

Используйте самый простой параметр, который соответствует типу файла и как часто он изменяется.

Сохранение исходного кода в Git, а не зависимостей

Используйте Git для файлов, которые команда редактирует напрямую. Сохраняйте зависимости из репозитория и доставляйте их с помощью управления пакетами.

  • Поместите исходные файлы в Git.
  • Храните библиотеки DLL, файлы библиотеки и другие зависимости за пределами репозитория.
  • Используйте управление пакетами для версии и развертывания зависимостей.

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

Не коммитьте результаты сборки

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

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

Хранение небольших двоичных файлов в Git

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

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

Это важно

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

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

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

  • Git сохраняет полное содержимое каждой версии.
  • Размер репозитория растет со временем.
  • Операции клонирования, создания ветки, загрузки и переключения замедляются.

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

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

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

Что такое хранилище больших файлов Git (Git LFS)?

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

Git LFS:

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

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

Git LFS сохраняет рабочий процесс Git при перемещении большого содержимого файла из основного репозитория.

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

службы Azure DevOps полностью поддерживают Git LFS и предлагают его бесплатно. Чтобы использовать LFS, установите клиент Git LFS, настройте отслеживание файлов, которые вы хотите хранить в LFS, а затем отправьте изменения в Azure Repos.

Инструкции по Azure DevOps Server и Kerberos см. в статье Kerberos и Git LFS.

Ограничения Git LFS

У Git LFS по-прежнему есть несколько нюансов, которые стоит заранее учесть:

  • Каждый клиент Git должен установить клиент Git LFS и понять его конфигурацию отслеживания.
  • Если клиент не установлен или неправильно настроен, клонированные копии загружают данные указателя вместо двоичного файла.
  • Git не может объединить разные версии двоичного файла, поэтому товарищи по команде по-прежнему должны координировать изменения.
  • Git LFS предоставляет блокировку файлов, но пользователям по-прежнему нужно извлечь последнюю копию перед началом работы.
  • Azure Repos не поддерживает Secure Shell (SSH) для репозиториев с файлами, отслеживаемыми Git LFS.
  • Перетаскивание двоичного файла в веб-интерфейс фиксирует двоичный файл в репозитории, а не указатель LFS.
  • Большие отправки могут быть ограничены доступным бесплатным пространством, текущей рабочей нагрузкой и ограничением на отправку в один час.

Формат файла Git LFS

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

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

Примечание.

  • URL-адрес GitHub, включенный для значения версии, определяет только тип файла указателя LFS. Это не ссылка на двоичный файл.
  • Для Git LFS до версии 2.10.0 с Azure DevOps Server выполните обновление до Git LFS 2.10.0 или более поздней версии, чтобы использовать проверку подлинности Kerberos. Актуальные рекомендации см. в статьях Kerberos и Git LFS и Перенастройка Azure DevOps Server для использования Kerberos вместо NTLM.

Планирование Azure DevOps Server и Kerberos

Если вы используете Azure DevOps Server и аутентификацию Windows, предусмотрите использование Kerberos при использовании Git LFS. Git LFS 2.10.0 и более поздних версий поддерживает проверку подлинности Kerberos.

Если вам нужно обновить старые Azure DevOps Server руководства, начните с Kerberos и Git LFS и связанного Azure DevOps Server руководства по проверке подлинности.

Связанные материалы

  • Last updated on