Github имеет ограничение при нажатии большого файла. Поэтому, если вы хотите нажать большой файл на свое репо, вы должны использовать Git LFS.
Я знаю, что это плохая идея добавить двоичный файл в репозиторий git. Но если я использую gitlab на моем сервере и нет предела размера файла в репо, и мне все равно, что размер репо будет супер большим на моем сервере. В этом условии, какое преимущество git lfs? git clone или git checkout будет быстрее?
Одна специфичность Git (и других распределенных систем) по сравнению с централизованными системами состоит в том, что каждый репозиторий содержит всю историю проекта. Предположим, вы создали файл размером 100 Мб, измените его 100 раз таким образом, чтобы он плохо сжимался. В итоге вы получите репозиторий на 10 Гб. Это означает, что каждый клон будет загружать 10 Гб данных, есть 10 ГБ дискового пространства на каждой машине, на которой вы клонируете. Что еще более неприятно: вам все равно придется загружать эти 10 Гб данных, даже если вы git rm большие файлы.
Вставка больших файлов в отдельную систему, например, git -lfs, позволяет хранить только указатели на каждую версию файла в репозитории, поэтому каждый клон будет загружать только крошечный фрагмент данных для каждой ревизии. В выписке будет загружена только версия, которую вы используете, т.е. 100 Мб в приведенном выше примере. В результате вы используете дисковое пространство на сервере, но сохраняете большую пропускную способность и дисковое пространство на клиенте.
В дополнение к этому алгоритм, используемый git gc (внутри, git repack), не всегда хорошо работает с большими файлами. Последние версии Git достигли прогресса в этой области, и он должен работать достаточно хорошо, но использование большого репозитория с большими файлами в нем может в конечном итоге вызвать у вас проблемы (например, не иметь достаточного количества оперативной памяти для переупаковки вашего репозитория).