The future of large files in Git is Git 🔥 Горячее 💬 Длинная дискуссия
Большие файлы — давний враг Git: раздувают репозиторий, замедляют клонирование и дорого обходятся хостингам. С 2015 г. GitHub предлагает Git LFS, но он влечёт vendor-lock, плату за хранение, сложности отката и необходимость ставить расширение всем участникам.
Сегодня можно обойтись без LFS:
- Partial clone (
--filter=blob:limit=100k) скачивает только нужные большие файлы, ускоряя клонирование в 30–50 раз и уменьшая дисковый след до размеров LFS-чекаутов. - Недостаток: команды вроде
git blameтребуют до-загрузки, но для PNG-файлов это редко нужно.
Будущее — large object promisors:
Git-сервер будет прозрачно выгружать большие объекты в специальный remote, избавляя пользователей от LFS и хостинги — от лишних затрат.
Комментарии (244)
- Критикуют Git LFS за «проприетарность», но многие отмечают, что протокол открыт и работает и с GitLab, и с S3.
- Основные боли: сломанные офлайн-режимы, многократная аутентификация, высокие расходы на трафик и неочевидные команды при клоне.
- Альтернативы — git-annex, DVC, Oxen, datamon и просто «не класть большие файлы в git», а хранить их в Artifactory.
- Часть участников ждёт нативную поддержку больших файлов в самом Git, чтобы не помнить про
--filter=blob:noneи LFS-указатели.