В чем преимущество git lfs?

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

Я знаю, что добавлять двоичный файл в репозиторий git — плохая идея. Но если я использую gitlab на своем сервере и в репозитории нет ограничений на размер файла, и меня не волнует репозиторий размер должен быть очень большим на моем сервере. В этом случае, в чем преимущество git lfs? git clone или git checkout будет быстрее?


person Sanster    schedule 23.02.2016    source источник
comment
Вы сравнивали скорость соединения?   -  person SOFe    schedule 23.02.2016
comment
Нет. Я пытаюсь разобраться в принципе.   -  person Sanster    schedule 23.02.2016
comment
С git-lfs клонирование будет НАМНОГО быстрее. Оформить заказ чуть дольше, время на загрузку файлов поставил в lfs. Но если вам ДЕЙСТВИТЕЛЬНО нужно проверить некоторые двоичные файлы, вам подойдет lfs.   -  person Philippe    schedule 23.02.2016
comment
atlassian.com/git/tutorials/git-lfs   -  person Benny    schedule 08.09.2017
comment
Следует четко различать вариант использования, если большие файлы изменены (сильно) или просто статические ресурсы в репо. В случае, если большой файл был только что добавлен один раз, а затем никогда не изменялся, LFS не используется. В случае изменения больших файлов применяется принятый ответ.   -  person g.pickardou    schedule 05.02.2019


Ответы (1)


Одной из особенностей Git (и других распределенных систем) по сравнению с централизованными системами является то, что каждый репозиторий содержит всю историю проекта. Предположим, вы создаете файл размером 100 МБ, изменяете его 100 раз таким образом, что он плохо сжимается. Вы получите репозиторий объемом 10 ГБ. Это означает, что каждый клон будет загружать 10 ГБ данных, занимая 10 ГБ дискового пространства на каждой машине, на которой вы делаете клон. Что еще больше расстраивает: вам все равно придется загружать эти 10 ГБ данных, даже если вы git rm большие файлы.

Размещение больших файлов в отдельной системе, такой как git-lfs, позволяет вам хранить только указатели на каждую версию файла в репозитории, поэтому каждый клон будет загружать только крошечный фрагмент данных для каждой версии. Касса загрузит только ту версию, которую вы используете, т. е. 100 МБ в приведенном выше примере. В результате вы будете использовать дисковое пространство на сервере, но сэкономите много пропускной способности и дискового пространства на клиенте.

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

person Matthieu Moy    schedule 23.02.2016
comment
Я всегда говорил о том, что это замедляет работу репозитория с течением времени, но это отличный конкретный пример! Спасибо, что показали, как размер сочетается с потреблением ресурсов! - person CTS_AE; 03.05.2019
comment
Итак, использование LFS хорошо, только если вы часто изменяете эти большие файлы? Что, если я хочу сохранить в репозитории некоторые программные пакеты, которые я использую, но никогда не изменяю? - person sanjivgupta; 12.04.2020
comment
@sanjivgupta В этом сценарии LFS будет иметь очень мало преимуществ. Если вы будете следовать процессу gitlfs, вы пометите файлы как двоичные; тогда, если доступ к файлу осуществляется с помощью git diff, это предотвратит его возможный сбой из-за большого файла. Кроме того, если вы решите обновить один из этих пакетов в будущем, вы получите предполагаемые преимущества lfs, клонируя только самые последние версии для ветки, из которой вы клонируете. При всем при этом вы должны использовать менеджер пакетов для этого сценария, когда это возможно. - person Mark Clark; 23.04.2020