Популярное
Свежее
Моя лента
Сообщения
Рейтинг
Пополнить Steam
Низкая комиссия
Викторина
Темы
Игры
Офтоп
Гайды
Кино и сериалы
Музыка
Ночной музпостинг
Вопросы
Творчество
Железо
Милые животные
Показать все
DTF
Granger
1990 - 2025
О проекте
Правила
Реклама
Приложения
AssetIQ
Gamedev

Git LFS для геймдева: когда включать, как настроить и как не сломать репозиторий

Когда включать LFS, что отмечать и где не переборщить
Когда включать LFS, что отмечать и где не переборщить

Итак, Дмитрий Яковлев, спасибо за идею!

@liveworkdie
@liveworkdie

Частый сценарий: репозиторий пухнет, клон тормозит, история забита бинарниками. Git LFS решает это, если включить вовремя и не тащить туда всё подряд.

Ниже — что отдавать в LFS, как стартовать за час и как аккуратно мигрировать на следующей неделе.

TL;DR

  • Когда нужен. У вас есть крупные бинарные ассеты (FBX, WAV/OGG, у UE — *.uasset/*.umap, у DCC — *.blend, *.spp, *.psd и т. п.), и они часто меняются.
  • Что делать. Поставьте LFS, отметьте шаблоны файлов, добавьте лёгкую проверку перед коммитом, зафиксируйте правила в README.
  • Важно запомнить. LFS хранится и тарифицируется отдельно (хостинг/трафик). Миграция задним числом переписывает историю — делаем это осознанно, в «замороженное» окно.
  • Это не свалка. Не тащите в LFS всё подряд. Ориентир — порог размера (например, ≥ 5–10 МБ) и/или «по типу» (все игровые бинарники UE/Unity, исходники DCC).

Зачем нам LFS

Обычный Git хранит большие бинарники полными копиями на каждое изменение.

LFS же выносит содержимое в отдельное хранилище и оставляет в истории маленький указатель.

Результат: быстрее clone/fetch, чистая история, видимые квоты и понятный контроль расхода.

Командные бонусы: быстрее онбординг, меньше падений CI на скачивании, прозрачные отчёты о том, кто съел место в хранилище.

Что отдавать в LFS (а что — нет)

  • Суём в LFS: UE (*.uasset, .umap), 3D (.fbx, *.glb, *.blend, .abc), большие текстуры (.tga, *.exr, крупные .png), исходники графики (.psd, *.psb, *.spp, .sbsar), аудио/видео (.wav, *.ogg, .mp4), тяжёлые инструменты (.ztl, *.hip).
  • Оставляем в Git: код и конфиги (*.cs, *.cpp, *.uplugin, *.ini, *.json, *.yaml), мелкие изображения/иконки, скрипты и документация.

Простой тест: файл бинарный и часто меняется? Почти наверняка лучше кинуть в LFS.

Старт за 1 час

Цель — подключить LFS для всех новых изменений.

Установить LFS локально и на CI:

git lfs install

Отметить типы (пример — под UE/DCC, адаптируйте под стек):

git lfs track "*.uasset" "*.umap" "*.fbx" "*.glb" "*.blend" "*.abc" \ "*.tga" "*.exr" "*.psd" "*.psb" "*.spp" "*.sbsar" \ "*.wav" "*.ogg" "*.mp4" "*.ztl" "*.hip" git add .gitattributes && git commit -m "chore: enable LFS for assets"

Добавить лёгкую проверку перед коммитом (это будет скорее подсказка, а не запрет).

Смысл: Если бинарник >N-го количества МБ не в LFS — предложить git lfs track.

Зафиксировать правила в README: что в LFS/не в LFS, где смотреть квоты, что делать при ошибке «недостаточно трафика/хранилища».

Важно: это не чистит старую историю — мы просто перестаём её раздувать.

AIQ

Миграция за неделю

Нужно, если история уже раздутa и клон медленный.

Краткий экспресс-план:

  • Сделать зеркало/бэкап. Согласовать «freeze» (никто не пушит).
  • Уточнить список шаблонов для LFS.
  • прогнать миграцию (на GitHub/GitLab есть штатные инструменты; из CLI подойдёт git filter-repo):
# пример для filter-repo: перенос истории указанных расширений в LFS git filter-repo --force --use-base-name \ --path-glob '*.uasset' --path-glob '*.umap' --path-glob '*.fbx' \ --path-glob '*.blend' --path-glob '*.tga' --path-glob '*.exr' \ --to-subdirectory-filter . git lfs migrate import --include="*.uasset,*.umap,*.fbx,*.blend,*.tga,*.exr"
  • Проверить: чистый клон → сборка проекта.
  • Сделать force-push (если требуется) и разослать короткую инструкцию коллегам: «переклонируйте/перефетчьте, почистите кэши».

Риски и что с ними делать: открытые PR/форки потребуют обновления; на некоторых платформах лимиты LFS по трафику/хранилищу — планируйте окно и квоты.

Типичные грабли и как на них не наступить

  • Квота LFS кончилась. Найти «тяжёлых заливальщиков» по отчётам хостинга; временные артефакты хранить в артефактах CI/релизах, не в LFS.
  • Пуш не проходит. Чаще всего трафиковый лимит — перенесите окно загрузок, дробите пакеты.
  • Залили огромный файл мимо LFS. Добавить тип в track, перезалить; если уже в main — маленькое окно на правку истории.
  • Конфликты в бинарниках. Включить file-locking для спорных типов (*.uasset и т. п.).

Мини-политика проекта (пара абзацев вместо талмуда)

В LFS: все UE-бинарники, FBX/GLB/BLEND, TGA/EXR и PNG > N-го кол-ва МБ, аудио/видео, исходники DCC.

В Git: код, конфиги, мелкие изображения, скрипты, доки. Порог N=5–10 МБ.

Артефакты билдов — в хранилище CI/релизов. Для конфликтных бинарников используем locking. Раз в неделю смотрим дашборд квот.

Короткий FAQ (сори за мат)

LFS бесплатен?

Базово — да, но хранилище и трафик на популярных платформах лимитируются. Проверяйте тариф/квоты заранее.

Нужно ли тащить в LFS все PNG?

Нет. Ставьте порог по размеру (например, ≥ 5–10 МБ) и/или ограничивайте типами, которые точно тяжелые (*.tga, *.exr, исходники *.psd, *.spp).

UE-проект целиком в Git — что делать?

Практика — отправлять все *.uasset/*.umap в LFS. Плюс крупные внешние источники (аудио/видео).

Мы уже раздулись — поздно ли чинить?

Никогда не поздно. Сначала перестаём усугублять, потом мигрируем историю в согласованное окно.

Итог

Git LFS — это не «магия», а дисциплина: правильно отметить типы, не хранить артефакты билдов в LFS, держать порог по размеру и один раз аккуратно переписать историю. На выходе — предсказуемый репозиторий: быстрее клон, чище история, прозрачные квоты.

Всем добра!

13
1
1 комментарий