Creating a Version Control System for Game Projects
Binary files are the key feature of a game dev repository that makes standard git-workflow unworkable. Textures in PNG/PSD, 3D models in FBX, audio in WAV/OGG, videos—all this doesn't diff, takes gigabytes, and instantly makes git clone impossible without special tools.
Git LFS (Large File Storage) is the basic solution, but its configuration in a game dev project requires precise definition: what goes to LFS, what doesn't. If scripts or JSON configs end up there—we lose normal diff in code review. If large textures don't go there—repository grows to several GB per month.
Setting Up Git LFS for Unity/Unreal
.gitattributes for Unity project should include:
*.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
Meanwhile .cs, .json, .yaml, .asmdef—without LFS: they're text, important to diff.
Critical Unity setting: Force Text serialization. Edit → Project Settings → Editor → Asset Serialization Mode = Force Text. This converts .asset, .prefab, .unity from binary format to YAML-text. Now you can diff and merge them. Without this setting, merging scenes is impossible—each conflict requires manual "my version or theirs" choice.
Alternative for large studios—Perforce (Helix Core). P4 natively works with binary files, supports exclusive checkout (prevents conflicts on binary files), scales to large repositories (terabytes). Entry barrier higher, but for team 10+ with large asset volume—justified choice. Unreal Engine itself actively uses Perforce.
Branching Strategy for Game Projects
Game project has specifics compared to web app: frequent asset updates from artists, parallel level work, need to maintain playable version at any time.
GitFlow adapted for game dev:
-
main—stable version, always runs without critical bugs -
develop—integration branch, features merge here -
feature/name—short-lived branches for specific systems -
art/name—branches for large asset updates (new level, character pack) -
hotfix/description—urgent fixes on top of main
art/ branches live longer than feature/ and merge in large batches—this reduces conflicts when artists work together.
Trunk-based development—alternative for small teams (2–4 people). Everyone works in main, short branches live no more than 2 days. Requires good CI and feature flags for unfinished features.
Scene and Preference Management
Scenes in Unity are the main merge conflict source. Standard approach: each developer doesn't touch someone else's scene without agreement. Better: split levels into Subscenes (via Multi-Scene Editing or Addressables Scene Loading). Artist works on Art-subscene of level, programmer—on Logic-subscene. No conflicts because they're different files.
In Unreal—World Partition with Level Streaming. Each streamer region can be edited independently.
Team Tools
Beyond VCS itself—we set up integrations:
- GitHub / GitLab / Bitbucket—hosting + code review workflow (Pull Requests, branch protection rules)
- Unity Version Control (Plastic SCM)—alternative to Git LFS from Unity, with native GUI in editor. More convenient for non-technical team members (artists, level designers)
-
Conventional Commits—standard for commit messages:
feat(combat): add parry mechanic,fix(ui): inventory count overflow on 3-digit numbers
Real situation we solve: startup, 5 people, git without LFS, scene in binary format. Repository grew to 14 GB in 3 months, clone takes 40 minutes, merge scenes—manual pick one of two. Migration took 4 days: git-lfs migrate import for all binary files, Force Text serialization enabled, .gitattributes configured, team trained. Result: repository 1.2 GB (without LFS objects), clone in 5 minutes.
| Task Scale | Estimated Timeline |
|---|---|
| Git LFS setup + .gitattributes + Force Text | 1–2 days |
| Full VCS setup (git + branching strategy + CI hooks) | 3–5 days |
| Migrate existing repository to LFS | 2–4 days |
| Perforce setup for large studio | 1–2 weeks |
Cost calculated after analyzing current repository state and team.