Есть ли реальная необходимость использовать Git LFS?

Есть такой "плагин" к Git — Git LFS. Я его использую в совокупности с Gitlab, но тут задумался, а есть ли реальная необходимость в его использовании? Да, Git посчитает чуть меньше SHA1-хэшей, но по современным меркам это тривиальная процедура. А использование LFS требует наличие необходимого бинарного пакета git-lfs везде, куда складывается софт, иначе есть риск получить неконсистентную копию. А ещё нужно, чтобы сервер репозиториев его поддерживал, это, вроде, не проблема, но всё же, это не essential расширение.

То есть, какие реальные бенефиты от использования Git LFS? Компактнее репозиторий? Не заметил. Скорость работы? Тоже не особо заметно. Тогда что?

Есть репозитории с несколькими паттернами:

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

Дополнительно:

Есть ли реальная необходимость использовать Git LFS?

Люди используют? Значит есть.

У Git-LFS только два выигрыша.
1. Перескок от ветки к ветке происходит быстрее.
2. Многие хостинги имеют отдельную политику для крупных файлов, что позволяет как-то жить, не упираясь в пределы дискового места.

Вопрос не в том, есть ли необходимость, а в том, в каких именно ситуациях следует использовать LFS.

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

передача файлов всё равно занимает одинаковое время

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

Git посчитает чуть меньше SHA1-хэшей

Почему вы так решили. Хэши в любом случае считаются все.

Ответы:

Мое мнение - абсолютно бесполезен (из-за особенностей реализации и избытка функционала).

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

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

git-lfs работает очень не эффективно, банальный git clone репозитарием из 20-гигабайтовых файлов требует сравнимый объем оперативной памяти, потому что там на любой файл идет diff/patch, что бессмысленно для бинарных файлов в подавляющем большинстве случаев.

схема наглядно показывает зачем нужен плагин

если коротко и просто - в проекте много овер гиг файлов которые часто обновляются? этот плагин для вас

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