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