Game Development Version Control Setup
You launch a game project and find that the repository has ballooned to 14 GB in a couple of months, and merging changes from the artist's branch is a saga. As a team with 10 years of experience in gamedev (over 50 successfully configured projects), we know how to avoid this. A proper version control system is the foundation of any game development. Without it, you lose days on merge conflicts and manual backups. We'll set up your VCS so that your team works in parallel without stepping on each other's files.
Binary files are the main peculiarity of a gamedev repository that makes a standard Git workflow impractical. Textures in PNG/PSD, 3D models in FBX, audio in WAV/OGG, videos—all of these cannot be diffed, take gigabytes, and instantly make git clone impossible without special tools.
Git LFS (Large File Storage) is the basic solution, but configuring it for a gamedev project requires precise definition: what goes into LFS and what does not. If scripts or JSON configs end up there, you lose normal diff in code review. If large textures are not added, the repository grows to several GB per month.
How to Configure Git LFS for Unity/Unreal?
.gitattributes for a 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 are textual and must be diffable.
Why Force Text serialization is Important?
Critical Unity setting: Force Text serialization. Edit → Project Settings → Editor → Asset Serialization Mode = Force Text. This converts .asset, .prefab, .unity from binary to YAML text. Now they can be diffed and merged. Without this setting, merging scenes is impossible—every conflict requires manual "take mine or theirs". We guarantee that after our configuration, merge conflicts become rare and easily resolvable.
An alternative for large studios is Perforce (Helix Core). P4 natively handles binary files, supports exclusive checkout (prevents conflicts on binaries), and scales to large repositories (terabytes). The entry threshold is higher, but for teams of 10+ with large asset volumes, it's a justified choice. Unreal Engine itself actively uses Perforce. For details, see the official Perforce documentation.
Difference Between Git LFS and Perforce for Game Projects
| Criteria | Git LFS | Perforce (Helix Core) |
|---|---|---|
| Binary file handling | Via LFS, needs configuration | Native support |
| Merge conflicts | Risk with parallel edits | Exclusive checkout eliminates conflicts |
| Repository size | Slow clone with large LFS cache | Linear scaling to TB |
| Price | Free for any size | Paid license per user |
| Setup complexity | Low (Git LFS self-learning) | High (requires administration) |
| Recommended team size | 1–10 people | 10+ people |
Branching Strategy for a Game Project
A game project differs from a web application: frequent asset updates from artists, parallel work on levels, need to maintain a playable version at any moment.
GitFlow adapted for gamedev:
-
main— stable version, always runs without critical bugs -
develop— integration branch, features merge here -
feature/feature-name— short-lived branches for specific systems -
art/resource-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 are merged in large batches—this reduces the number of conflicts when artists work.
Trunk-based development is an 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 incomplete features.
Managing Scenes and Preferences
Scenes in Unity are the main source of merge conflicts. Standard approach: each developer does not touch another's scene without agreement. Better: split levels into Subscenes (via Multi-Scene Editing or Addressables Scene Loading). The artist works on the Art subscene of the level, the programmer on the Logic subscene. No conflicts because they are separate files.
In Unreal — World Partition with Level Streaming. Each streaming region can be edited independently.
Common mistakes when setting up VCS:
- Incorrect .gitattributes: scripts in LFS lose diff.
- Binary scenes: without Force Text, merging is impossible.
- No art/ branches: artists merge into develop and break the build.
- Exclusive checkout not set for binary files (in Perforce).
- Ignoring .gitignore: Library, Temp, Logs get in.
Tools for the Team
In addition to the VCS itself, we configure integrations:
- GitHub / GitLab / Bitbucket — hosting + code review workflow (Pull Requests, branch protection rules)
- Unity Version Control (Plastic SCM) — an alternative to Git LFS from Unity, with native GUI in the editor. More convenient for non-technical team members (artists, level designers)
- Conventional Commits — commit message standard:
feat(combat): add parry mechanic,fix(ui): inventory count overflow on 3-digit numbers
What's Included in the Setup
- Audit of the current repository and size estimation.
- Configuration of .gitattributes, LFS, and Force Text serialization.
- Development of a branching strategy tailored to your project.
- Integration with CI/CD (GitHub Actions, GitLab CI).
- Team training (1-hour webinar).
- Documentation of the process and a checklist.
- Post-setup support (2 weeks).
Real Case We Solved
A startup, 5 people, Git without LFS, scenes in binary format. The repository grew to 14 GB in 3 months, clone took 40 minutes, merging scenes required manual choice of one of two versions. The migration took 4 days: git-lfs migrate import for all binary files, enabling Force Text serialization, configuring .gitattributes, training the team. Result: repository 1.2 GB (without LFS objects), clone in 5 minutes, savings on team downtime of several thousand dollars per month.
Timeline Estimates
| Task Scale | Estimated Time |
|---|---|
| Setup Git LFS + .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 |
| Configure Perforce for a large studio | 1–2 weeks |
Next Steps
The cost of configuration is calculated individually after analyzing the current state of the repository and team. Request a consultation to get a detailed plan and timeline. We guarantee that your repository will become lightweight, merge conflicts will disappear, and your team will work in parallel without downtime. Contact us to discuss your project.





