Game Development Version Control Setup

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

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

1. Audit of the current repository and size estimation.
2. Configuration of .gitattributes, LFS, and Force Text serialization.
3. Development of a branching strategy tailored to your project.
4. Integration with CI/CD (GitHub Actions, GitLab CI).
5. Team training (1-hour webinar).
6. Documentation of the process and a checklist.
7. 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

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.

How to plan a game project?

Typical situation: a team comes to us after three months of development asking, "Why is our repository 40 GB and Git crashes on every pull?" The answer is almost always the same: PNG textures and FBX files committed directly without Git LFS, causing the repository history to bloat to an unworkable state. This is solvable, but rewriting history in a live project is a painful process that could have been easily avoided.

Game planning is not about Gantt charts. It's about technical decisions in the first two weeks that won't become problems three months later. With over 7 years of experience shipping 50+ titles across mobile, PC, and console, our team has seen these pitfalls firsthand.

Why game planning is not about Gantt?

Work schedule is just the tip of the iceberg. Real game project planning includes:

• Strict definition of target platforms and minimum requirements (e.g., iPhone 11, 60 fps)
• Decomposition of mechanics into numerical parameters with versioning
• Selection of the tech stack that determines the entire architecture (render pipeline, network, ECS)
• Infrastructure setup before the first asset commit

Without this, a "plan" is just a list of tasks with no foundation. A month later, you discover that the Unreal project can't be built for mobile platforms, or that ECS was overkill for a simple runner. Time wasted, budget spent on prototypes that need to be rewritten. Proper planning reduces these risks by a factor of 3–5x.

Documentation: GDD as a living tool

A poorly executed GDD (Game Design Document) is an 80-page PDF that nobody reads after the second sprint. A well-executed GDD is a structured knowledge base that the team actually uses every day.

What should be in the GDD?

Minimum set without which development cannot begin:

• Gameplay systems — precise description of each mechanic with parameters. Not "character jumps," but "jump: height 2.4 units, air time 0.6 sec, 150 ms coyote time, double jump allowed, landing blocks attack for 200 ms." Numbers may change during balancing, but they must be recorded and versioned.
• Technical constraints — target platforms, minimum hardware requirements, memory and draw call limits. If the game must run on iPhone 11 at 60 fps, this constraint affects all art decisions from the start.
• Scope and features — explicit list of what's in MVP and what's deferred. "Maybe we'll add crafting" is not planning; it's a source of feature creep.
• References — specific games with specific mechanics taken as a basis. "Like Dark Souls but faster" is a working reference for a combat designer.

How we manage GDD

We use Notion or Confluence — the GDD lives as a wiki, not a file. Changes are visible in history, comments can be left, mechanics are cross-referenced. Technical design and artistic design are stored in separate sections but linked. Each mechanic has a status: in development, ready, under review, frozen. This allows you to understand the real state of the project at any moment without phone calls.

What technical architecture decisions are critical for game planning?

Tech stack selection is not a religion

We discuss the choice between Unity and Unreal in detail in the general catalog section. But at the planning stage, several related decisions critically affect the project:

• Render pipeline in Unity. URP — for mobile and VR. HDRP — for PC/consoles. Built-in (Legacy) — only if taking over an old project. Changing pipeline mid-development means rebuilding all materials. Decision is made on the first commit day.
• Game object architecture. Classic MonoBehaviour vs ECS (Entity Component System via Unity DOTS). ECS provides performance gains on thousands of objects but dramatically increases code complexity. Overkill for hyper-casual games, necessary for strategies.
• Network architecture. If multiplayer is planned, decision is made before the first game mechanic. Single-player and networked code are fundamentally different: in a networked game, every state change must be explicit and synchronizable.

ScriptableObjects as configuration layer

In Unity, we use a ScriptableObject-oriented approach to store game data. Weapon configurations, enemy parameters, level settings — all are ScriptableObject assets, not hardcoded values. This allows game designers to tweak balance without programmer involvement and without rebuilding the project.

How to manage version control and assets?

This is the area where most small teams waste time in the most frustrating way. Our engineers have seen teams lose 2–3 weeks migrating to Git LFS mid-project — time that could have been saved with a single .gitattributes file.

Git + Git LFS

Standard Git is not designed for binary files. A 4K texture in PNG weighs 20–50 MB. Committing it as a regular file bloats the repository history catastrophically fast. Git LFS stores binary files separately, placing only pointers in Git history. It is configured once in .gitattributes:

*.png filter=lfs diff=lfs merge=lfs -text
*.fbx filter=lfs diff=lfs merge=lfs -text
*.psd filter=lfs diff=lfs merge=lfs -text
*.unitypackage filter=lfs diff=lfs merge=lfs -text
*.mp3 filter=lfs diff=lfs merge=lfs -text
*.wav filter=lfs diff=lfs merge=lfs -text

This should be set up before the first asset commit. Afterwards, a painful migration can cost significant developer time. Git LFS reduces clone time by 10x compared to standard Git for large repositories.

Perforce

An alternative for large Unreal projects. Epic Games themselves use Perforce. It handles very large repositories (hundreds of GB) better, with native support in Unreal Editor. Higher infrastructure cost and setup complexity.

Branching

For game projects, we use a simplified Git Flow: main, develop, feature/*, release/*. Rule: never commit anything to main that hasn't passed QA. Violating this turns "last stable version" into a meaningless term.

CI/CD for game projects

Automated builds on every push solve the "it works on my machine" problem. Pipeline includes:

1. Unity license activation (headless)
2. Run tests (Unity Test Runner)
3. Build for Android (APK/AAB)
4. Build for iOS (Xcode project)
5. Build for PC (Standalone)
6. Upload artifacts to S3 or Firebase App Distribution

Build time: 15–40 minutes. The team gets fresh builds without manual work. Automated CI/CD reduces integration bugs by 50–70% according to internal metrics.

GameCI — GitHub Actions for Unity. Unity Cloud Build — hosting from Unity, easier setup, more expensive with many builds. Jenkins — full control, used for console platforms.

Sample project start checklist:

• [ ] Target platforms and minimum requirements defined
• [ ] Render pipeline and object architecture selected
• [ ] Git LFS configured with .gitattributes before first commit
• [ ] GDD created in wiki with status separation
• [ ] CI/CD configured (at least GameCI)
• [ ] MVP scope defined

Deliverables and scope of work

• Documentation: technical specifications, GDD (MVP scope), architectural diagram, data models.
• Repository setup: Git + LFS, branching rules, project template, code conventions.
• CI/CD: build configuration for all target platforms, automated testing.
• Access: to repository, CI/CD, bug tracker; team training on tool usage.
• Support: first month of development assistance — answering questions, adjusting settings, reviewing architectural decisions.

Timeframes for planning

Total before full production: 4–6 weeks. This is not bureaucracy — it's insurance against rewriting, saving up to 40% of production time (equivalent to $15k–$30k in rework for a typical team).

How does game planning prevent technical debt?

A planning mistake in the first sprint costs 10 times more to fix than in the prototype phase. Wrong tech stack choice or lack of LFS leads to architecture rebuilds, lost commits, and team demotivation. Proper game planning is an investment that pays off with 30% fewer bugs and an average of 2 months faster release. Our certified Unity engineers guarantee that your foundation is solid — we've seen what breaks, and we know how to avoid it.

Evaluate your project — contact us for a consultation and a detailed first-steps plan. Order game planning services and avoid the typical pitfalls we see in 90% of inquiries. Get in touch to start planning your game today.