Я рассматриваю возможность использования Git LFS для репозитория, который будет содержать файлы ISO и установочные файлы, которые используются нашими инструментами построения образа системы (в данном случае Packer). Затем мы добавим его как подмодуль нашего основного репо, в котором есть сценарии сборки, чтобы его можно было интегрировать в нашу цепочку инструментов CI.
Насколько я понимаю Git LFS, большие файлы заменяются указателем, поэтому запросы репо и обслуживание выполняются быстро, а затем файлы загружаются по другому каналу.
Однако, когда мы добавляем файлы, они будут иметь номер версии в имени, поэтому их не нужно будет обновлять (например, ubuntu-16.04.4-server-amd64.iso
). Их также не нужно будет удалять, потому что мы будем ссылаться на конкретные версии по этому полному имени в сценариях сборки. По сути, мы всегда будем добавлять и редко (если вообще когда-либо) обновлять или удалять.
Похоже, что Git LFS в основном предназначен для обновления / удаления. Есть ли еще какие-либо технические преимущества для нашего варианта использования?
Только текущие файлы, используемые в вашей ветке, будут загружены из git lfs. Файлы из других веток или прошлых коммитов не будут загружены.
Если вы поместите все в стандартный репозиторий git, все всегда будет клонировано, включая удаленные большие файлы которые в истории.
Таким образом, git lfs позволит вам быстрее работать на вашем сервере сборки, поскольку для клонирования и загрузки требуется меньше времени.
Я полагаю, что это также был бы простой способ обеспечить постоянную доступность этих зависимостей, не полагаясь на какой-либо другой инструмент.
It seems like Git LFS is mainly for updating / deleting.
Git-LFS в основном предназначен для уменьшения размера репозитория. git clone
обычно загружает весь репозиторий, поэтому git-lfs
в основном влияет на clone
. Репозиторий включает все файлы и все версии этих файлов, включая удаленные.
Если вы сделаете небольшое обновление Ubuntu и git rm ubuntu-16.04.4-server-amd64.iso
и git add ubuntu-16.04.5-server-amd64.iso
, вы сохраните два ISO-образа. Еще одно обновление и его три. Потом четыре. Пять. Шесть. Без git-lfs
каждый должен загрузить и сохранить все эти старые удаленные ISO-образы.
Если вы собираетесь хранить большие файлы, такие как ISO-образы операционной системы или медиафайлы, они быстро увеличивают размер репозитория. Это означает, что любому, кто клонирует ваш репозиторий, придется тратить время и пропускную способность, чтобы загрузить все, и тратить на все дисковое пространство. Это раздувает ваш процесс разработки и заставляет людей не решаться загружать 20-гигабайтный репозиторий только для работы с несколькими текстовыми файлами.
Are there any remaining technical advantages for our use case?
Да. Использование git-lfs
не требует больших затрат. Эта стоимость будет самой низкой, если вы воспользуетесь ею раньше, чем позже.
Вы можете использовать git-lfs
позже, но к этому есть некоторые ограничения. Если вы используете его для существующих файлов, они будут в git-lfs
в будущем, но их старые версии останутся в истории. Вы можете используйте BFG для перезаписи истории, чтобы задним числом поместить существующие большие файлы в git-lfs
, но переписывать всю историю - это не то, чем вы хотите часто заниматься. Вероятно, вам стоит использовать git-lfs
раньше, чем позже.
Вот хорошее изложение того, что нужно, чтобы переключиться позже.
Использование git-lfs
на раннем этапе означает, что разработчикам не нужно много думать о том, следует ли помещать что-либо в репозиторий только потому, что он слишком большой. Если что-то, по их мнению, должно быть в системе контроля версий, они помещают это в систему контроля версий, независимо от размера. Это упрощает процесс принятия решений разработчиком и делает репозиторий более здоровым. Если вам нужно, скажем, иметь шесть разных ISO-образов операционных систем в репозитории для тестирования, они могут это сделать, не обсуждая раздувание репозитория.
Это также означает, что вам не нужно искать обходные пути, чтобы учесть раздувание репозитория. Существуют различные способы клонирования только части репозитория, но все они добавляют сложности. Есть средства, позволяющие Git хранить сжатые ISO-образы и архивы более эффективно, вы распаковываете их и позволяете Git хранить их как обычные файлы, но это опять же добавляет сложности. git-lfs
означает, что вы можете все упростить (r).
Наконец, сторона хранения git-lfs
гибкая. Вы не обязаны Github или какому-либо конкретному сайту Git для хранения LFS.