Когда один файл считается слишком большим для git?

Question

Резюме

У меня есть git-репозиторий для отслеживания моих курсов в универе.Некоторые слайды лекций в формате .pdf иногда бывают довольно большими (20-30 МБ), что заставляет меня задуматься, когда обычная мудрость не помещает большие файлы в git! начинает применяться?

Я привожу свою ситуацию в качестве примера, но меня действительно интересуют общие пределы размера файла / частоты изменений, которые следует учитывать.

Пример Case

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

Насколько я знаю, GitHub блокирует файлы размером> 1 ГБ.Однако используемый мной репозиторий git размещен на частной машине объемом 1 ТБ, которой я поделюсь с другом, поэтому я предполагаю, что применяются другие ограничения?

В общем, я бы никогда не добавил в git базы данных> 100 МБ, но применимо ли это правило для файлов размером 20-50 МБ (слайдов лекций), которые никогда, возможно, не изменятся?

Answer 1

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

Типичный совет, когда люди говорят о больших файлах, - указать им Git Large File Storage (LFS).Git LFS позволяет указать эти большие файлы, удалив их из самого хранилища и поместив в отдельное хранилище LFS.Когда вы клонируете репозиторий, вы получите метаданные о файлах, достаточно информации, чтобы при извлечении ветки git-lfs мог загрузить эти большие файлы из области хранения LFS и поместить их на диск.

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

Давайте сравним Git LFS с «чистым» git в нескольких областях:

Загрузки

В вашем сценарии вы не изменяете эти файлы.У вас есть одна ревизия, и вы хотите, чтобы она была проверена, всегда.Таким образом, приблизительная пропускная способность и время, используемые git-lfs и обычным git, ... одинаковы.

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

Хранение на диске

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

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

В результате, если вы зарегистрируете файл размером 10 ГБ, вам потребуется 20 ГБ: 10 ГБ для его хранения врабочий каталог, в котором вы можете получить к нему доступ, и еще 10 ГБ для хранения его как объекта в репозитории Git.(Это, опять же, предполагает, что содержимое плохо сжимается.)

Хостинг

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

Так что в ваш сценарий, если у вас естьдостаточно места на диске для двойного размера содержимого текущего рабочего каталога, тогда git (без Git LFS) - отличный выбор.