Поделиться через

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

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

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

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

Фиксация исходного кода, а не зависимостей

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

Что такое Git LFS?

При наличии исходных файлов с большими различиями между версиями и частыми обновлениями можно использовать Git Large File служба хранилища (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 имеет некоторые недостатки, которые следует учитывать перед его принятием:

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

File format

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

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

Примечание.

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

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

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