Потеря одного критического файла сцены или конфликт слияния в финальной неделе спринта может отбросить разработку на 2-3 рабочих дня назад. В геймдеве стандартный подход к контролю версий не работает из-за бинарных файлов, которые могут весить от 100 МБ до нескольких ГБ, что делает обычный Git бесполезным без дополнительных надстроек.
Git и проблема бинарных данных
Git проектировался для текстовых файлов (кода), поэтому он хранит полную историю изменений каждого файла. Если ваш 3D-художник обновит текстуру размером 50 МБ десять раз, репозиторий раздуется до 500 МБ, даже если итоговый файл один. Это приводит к тому, что клонирование проекта на новую машину занимает часы вместо минут.
Решение — Git LFS (Large File Storage). Он заменяет тяжелые файлы ссылками, храня сами данные на отдельном сервере. Практика показывает: без LFS проект с общим объемом ресурсов в 10 ГБ становится неработоспособным уже через 2-3 месяца активной разработки из-за переполнения локального хранилища .git.
Экспертный вывод: Git без LFS в геймдеве недопустим. Настраивайте .gitattributes сразу при создании проекта, иначе переписывать историю репозитория через BFG Repo-Cleaner будет долго и рискованно.
SVN: почему старый стандарт жив
В отличие от распределенного Git, SVN (Subversion) работает централизованно. Это дает ключевое преимущество для художников и геймдизайнеров: механизм Exclusive Lock (блокировка файла). В Git два человека могут править одну сцену, но слить бинарный файл (.unitypackage или .uasset) невозможно — придется выбирать одну версию, теряя работу другого.
Кейс: в команде из 5 человек (1 кодер, 2 моделлера, 2 левел-дизайнера) использование SVN сокращает время на разрешение конфликтов в сценах на 80%, так как дизайнер просто «забирает замок» на файл, и остальные видят, что объект редактируется.
Экспертный вывод: Если в команде больше 60% не-программистов, SVN или Perforce будут эффективнее Git за счет жесткого контроля доступа к бинарникам.
Стоимость инфраструктуры и лимиты
Бесплатные тарифы GitHub и GitLab ограничены по объему LFS (обычно до 1-2 ГБ), чего катастрофически мало для современного проекта. Переход на платные тарифы или self-hosted решения требует затрат: аренда VPS с быстрыми NVMe-дисками под репозиторий обойдется в $20–$60 в месяц для небольшой инди-студии.
Для сравнения: развертывание собственного сервера GitLab или SVN требует около 16 ГБ ОЗУ и 100+ ГБ SSD для комфортной работы команды из 5-10 человек. Ошибка новичков — ставить сервер на дешевый HDD, что замедляет операцию push/pull в 5-7 раз, создавая простои в работе всей команды.
Экспертный вывод: Для проектов с объемом ресурсов свыше 50 ГБ выгоднее один раз настроить собственный сервер на выделенном железе, чем переплачивать за облачные гигабайты ежемесячно.
Интеграция с движками и пайплайном
Правильная настройка .gitignore или .svnignore — это 50% успеха. Игнорирование папок Library (Unity) или Intermediate/Saved (Unreal Engine) критично: их объем может достигать 20-40 ГБ локального кэша, который не должен попадать в облако. Ошибка в этом файле приводит к конфликтам при каждом запуске движка.
Связка инструментов должна быть бесшовной. Например, когда используются инструменты для моделирования 3D-персонажей, файлы .blend или .max должны идти в LFS, а экспортированные .fbx — в основной поток. Это позволяет разделять «рабочие» исходники и «игровые» ассеты.
Экспертный вывод: Автоматизируйте проверку .gitignore через CI/CD или внутренний скрипт, чтобы один неосторожный коммит с папкой Library не «положил» сервер всей студии.
Вывод
Мой вердикт: для чистого кода и маленьких инди-проектов (до 5 ГБ данных) выбирайте Git + GitHub/GitLab. Для полноценных команд с тяжелым артом и сложным левел-дизайном — только SVN или Perforce из-за системы блокировок файлов. Начинайте с настройки .gitattributes/ignore в первый же день; избегайте хранения бинарников в основном дереве Git без LFS. Оптимальный стек для старта: Self-hosted GitLab + LFS на VPS с NVMe — это баланс между стоимостью и надежностью.
