Налаштування системи контролю версій для ігрових проєктів

Налаштування системи контролю версій для ігрових проєктів

Ви запускаєте ігровий проєкт і стикаєтеся з тим, що репозиторій розрісся до 14 ГБ за пару місяців, а злити зміни з гілки художника — ціла епопея. Ми, як команда з 10-річним досвідом у геймдеві (понад 50 успішно налаштованих проєктів), знаємо, як цього уникнути. Правильна система контролю версій — основа розробки будь-якої гри. Без неї ви втрачаєте дні на merge-конфлікти та ручний бекап. Ми налаштуємо VCS так, що команда працюватиме паралельно, не наступаючи один одному на файли.

Бінарні файли — головна особливість геймдев-репозиторію, яка робить звичайний 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: вони текстові, їх важливо дифувати.

Чому важлива Force Text serialization?

Критичне налаштування Unity: Force Text serialization. Edit → Project Settings → Editor → Asset Serialization Mode = Force Text. Це переводить .asset, .prefab, .unity з бінарного формату в YAML-текст. Тепер на них можна робити diff та merge. Без цього налаштування злиття сцен неможливе — кожен конфлікт потребує ручного вибору «моя версія або чужа». Ми гарантуємо, що після нашого налаштування merge-конфлікти стануть рідкісними та легко вирішуваними.

Альтернатива для великих студій — Perforce (Helix Core). P4 нативно працює з бінарними файлами, підтримує exclusive checkout (запобігає конфліктам на бінарних файлах), масштабується до великих репозиторіїв (терабайти). Поріг входу вищий, але для команди 10+ осіб з великим обсягом асетів — виправданий вибір. Unreal Engine сам активно використовує Perforce. Детальніше див. офіційну документацію Perforce.

Різниця між Git LFS та 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:

• Неправильний .gitattributes: скрипти в LFS втрачають диф.
• Бінарні сцени: без Force Text merge неможливий.
• Відсутність гілок art/: художники мержать у develop і ламають збірку.
• Не налаштований exclusive checkout на бінарні файли (в Perforce).
• Ігнорування .gitignore: потрапляють Library, Temp, Logs.

Інструменти для команди

Крім власне 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

Що входить у налаштування

1. Аудит поточного репозиторію та оцінка обсягу.
2. Налаштування .gitattributes, LFS та Force Text serialization.
3. Розробка branching strategy під ваш проєкт.
4. Інтеграція з CI/CD (GitHub Actions, GitLab CI).
5. Навчання команди (1 година вебінар).
6. Документація процесу та чек-лист.
7. Пост-налаштування підтримка (2 тижні).

Реальна ситуація, яку вирішуємо: стартап, 5 осіб, git без LFS, сцена в бінарному форматі. Репозиторій виріс до 14 ГБ за 3 місяці, clone займає 40 хвилин, merge сцен — ручний вибір один з двох варіантів. Міграція зайняла 4 дні: git-lfs migrate import для всіх бінарних файлів, включення Force Text serialization, налаштування .gitattributes, навчання команди. Підсумок: репозиторій 1.2 ГБ (без LFS-об'єктів), clone за 5 хвилин, економія на простої команди склала кілька тисяч доларів на місяць.

Вартість налаштування розраховується індивідуально після аналізу поточного стану репозиторію та команди. Замовте консультацію — отримаєте детальний план та терміни. Ми гарантуємо, що репозиторій стане легким, merge-конфлікти зникнуть, а команда зможе паралельно працювати без простоїв. Зв'яжіться з нами, щоб обговорити ваш проєкт.