Управление и хранение больших файлов в 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 (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.
• Хотя нет строгого ограничения размера файла, доступное свободное пространство сервера и текущая рабочая нагрузка может ограничить производительность и функциональные возможности.
• Ограничение времени отправки одного файла составляет один час.

Формат файла

Файл, записанный в репозиторий для отслеживаемого файла 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, и мы настоятельно рекомендуем вам обновить систему.