Создание системы контроля версий проекта игр
Бинарные файлы — главная особенность геймдев-репозитория, которая делает обычный git-workflow нерабочим. Текстуры в PNG/PSD, 3D-модели в FBX, аудио в WAV/OGG, видеоролики — всё это не диффуется, занимает гигабайты и моментально делает git clone невозможным без специальных инструментов.
Git LFS (Large File Storage) — базовое решение, но его настройка в геймдев-проекте требует точного определения: что в LFS, что нет. Если туда попадут скрипты или JSON-конфиги — теряем нормальный diff в code review. Если не туда попадут большие текстуры — репозиторий разрастается до нескольких ГБ за месяц.
Настройка Git LFS для Unity/Unreal
.gitattributes для Unity-проекта должен включать:
*.png filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.jpg filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.ogg filter=lfs diff=lfs merge=lfs -text
*.mp4 filter=lfs diff=lfs merge=lfs -text
*.asset filter=lfs diff=lfs merge=lfs -text
*.unity filter=lfs diff=lfs merge=lfs -text
*.prefab filter=lfs diff=lfs merge=lfs -text
При этом .cs, .json, .yaml, .asmdef — без LFS: они текстовые, их важно диффовать.
Критичная настройка Unity: Force Text serialization. Edit → Project Settings → Editor → Asset Serialization Mode = Force Text. Это переводит .asset, .prefab, .unity из бинарного формата в YAML-текст. Теперь на них можно делать diff и merge. Без этой настройки слияние сцен невозможно — каждый конфликт требует ручного выбора «моя версия или чужая».
Альтернатива для больших студий — Perforce (Helix Core). P4 нативно работает с бинарными файлами, поддерживает exclusive checkout (предотвращает конфликты на бинарных файлах), масштабируется до больших репозиториев (терабайты). Порог входа выше, но для команды 10+ человек с большим объёмом ассетов — оправданный выбор. Unreal Engine сам активно использует Perforce.
Branching strategy для игрового проекта
Игровой проект имеет специфику по сравнению с веб-приложением: частые ассет-обновления от художников, параллельная работа над уровнями, необходимость поддерживать играбельную версию в любой момент.
GitFlow адаптированный для геймдева:
-
main— стабильная версия, всегда запускается без критичных багов -
develop— интеграционная ветка, сюда вливаются фичи -
feature/название-фичи— короткоживущие ветки для конкретных систем -
art/название-ресурса— ветки для больших ассет-обновлений (новый уровень, пак персонажей) -
hotfix/описание— срочные фиксы поверх main
Ветки art/ живут дольше feature/ и мержатся крупными пачками — это уменьшает количество конфликтов при работе художников.
Trunk-based development — альтернатива для небольших команд (2–4 человека). Все работают в main, короткие ветки живут не больше 2 дней. Требует хорошего CI и feature flags для незавершённых фич.
Управление сценами и предпочтениями
Сцены в Unity — главный источник merge-конфликтов. Стандартный подход: каждый разработчик не трогает чужую сцену без договорённости. Лучше: разбить уровни на Subscenes (через Multi-Scene Editing или Addressables Scene Loading). Художник работает над Art-подсценой уровня, программист — над Logic-подсценой. Конфликтов нет, потому что это разные файлы.
В Unreal — World Partition с Level Streaming. Каждый стример-регион может редактироваться независимо.
Инструменты для команды
Помимо собственно VCS — настраиваем интеграции:
- GitHub / GitLab / Bitbucket — hosting + code review workflow (Pull Requests, branch protection rules)
- Unity Version Control (Plastic SCM) — альтернатива Git LFS от Unity, с нативным GUI в редакторе. Удобнее для нетехнических участников команды (художники, дизайнеры уровней)
-
Conventional Commits — стандарт сообщений коммитов:
feat(combat): add parry mechanic,fix(ui): inventory count overflow on 3-digit numbers
Реальная ситуация, которую решаем: стартап, 5 человек, git без LFS, сцена в бинарном формате. Репозиторий вырос до 14 ГБ за 3 месяца, clone занимает 40 минут, merge сцен — ручной выбор один из двух вариантов. Миграция заняла 4 дня: git-lfs migrate import для всех бинарных файлов, включение Force Text serialization, настройка .gitattributes, обучение команды. Итог: репозиторий 1.2 ГБ (без LFS-объектов), clone за 5 минут.
| Масштаб задачи | Ориентировочные сроки |
|---|---|
| Настройка Git LFS + .gitattributes + Force Text | 1–2 дня |
| Полный VCS setup (git + branching strategy + CI hooks) | 3–5 дней |
| Миграция существующего репозитория на LFS | 2–4 дня |
| Настройка Perforce для большой студии | 1–2 недели |
Стоимость рассчитывается после анализа текущего состояния репозитория и команды.