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

Самое фундаментальное различие между Git и другими инструментами управления исходным кодом (perforce, svn) заключается в том, что Git сохраняет полный снимок репозитория при каждой фиксации. Таким образом, когда у вас есть большой файл, моментальный снимок содержит сжатую версию этого файла (или указатель на большой двоичный объект файла, если файл не был изменен). Моментальный снимок репозитория хранится в виде графика в папке .git. Таким образом, если файл «большой», размер репозитория будет быстро расти.

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

• Размер файла. IMO, если размер файла превышает 10 МБ, вам следует рассмотреть возможность его сохранения в Git LFS.

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

• Тип файла. Нетекстовый файл, который нельзя объединить, подходит для хранилища Git LFS.

Получу ли я пользу от Git LFS с «большими файлами» размером всего 50 МБ? 20 МБ? 5 МБ? 1 МБ? Меньше 1 МБ?

В зависимости от того, как часто файл изменяется, вы можете извлечь выгоду из любого упомянутого размера. Рассмотрим случай, когда вы каждый раз делаете 100 коммитов, редактируя файл. Для файла размером 20 МБ, который можно сжать, скажем, до 15 МБ, размер репозитория увеличится примерно на 1,5 ГБ, если файл не хранится с использованием Git LFS.

LFS — это инструмент для обслуживания ресурсов проектов. Предположим, у вас есть проект с *.psd файлами, которые используются во внешнем интерфейсе. Эти файлы обычно большие, и версия файла не соответствует предыдущим версиям (git сохраняет историю изменений для текстовых файлов в коммитах, но для двоичных файлов этот подход не может быть использован. diff из двух .cpp файлов имеет значение, но diff из двух сырое фото нет.). Поэтому, если вы поместите ресурсы в репозиторий, его размер и время клонирования будут неприглядно расти. Кроме того, обслуживание будет трудным.

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

Что делает ЛФС? Он хэширует отслеживаемые файлы и сохраняет тему как указатели на исходные файлы. Храните исходные файлы в отдельной базе данных на стороне сервера. Локальные репозитории имеют все указатели в своей истории, но когда вы извлекаете определенный коммит, он извлекает только его содержимое. Таким образом, размер локального репозитория и время клонирования значительно уменьшатся.

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

Также обратите внимание, что у git есть проблема с файлами размером больше 4GB в Windows.