Compare
USourceControl vs Git + Git LFS
Git LFS patches Git to handle large files. USourceControl was designed around them from day one. For game projects, the difference adds up fast.
At a glance
Why teams switch
What Git LFS gets wrong for games
No pointer-file foot-guns
Git LFS replaces files with pointer files when LFS isn't configured correctly. Artists commit 134-byte text files instead of their 500 MB assets — and don't notice until the team tries to open them. USourceControl has no pointer layer; the file you commit is the file stored.
Predictable performance at scale
As Git LFS history grows, clones and fetches slow down even when LFS content is filtered. USourceControl's protocol is designed around per-file version timelines, so repository size doesn't bleed into day-to-day sync speed.
Locking for binary assets
Git LFS has locking support, but it requires LFS-aware Git clients, server support, and discipline. USourceControl has first-class locking in the desktop app so two artists can't silently diverge edits on the same .uasset.
Simple inclusive pricing
GitHub LFS bandwidth is billed separately in 50 GB packs. For a team pulling down nightly builds or trading multi-gigabyte assets, costs spiral. USourceControl bundles storage and bandwidth into one transparent per-user price.
When Git LFS is still a fine choice
We use Git ourselves. It shines when:
- Your team is all engineers fluent in Git workflow.
- You need Git-native features like PRs and rebasing for your code.
- Asset volume is modest enough that LFS bandwidth is affordable.
A common hybrid: keep code in Git, use USourceControl for content.
FAQ
Common questions
Why isn't Git LFS enough for game projects?
Git LFS bolts large-file handling onto a system designed for small text diffs. The pointer-file model is fragile — missing LFS config anywhere in the pipeline produces silent data loss. Bandwidth is billed separately and expensive at game-asset scale. Non-engineers struggle with the LFS workflow.
Can we keep our code in Git and use USourceControl for assets?
That's a common pattern. Keep your engine source (C++, C#, GDScript) in Git, and use USourceControl for content — .uasset, textures, audio, FBX, builds. We don't require you to put code in USourceControl.
What about Git's branching model?
Git's branching model is a real strength for text code, and we don't try to replicate it for binary assets where merging is often impossible anyway. Most game teams use locking on binaries and keep branch-heavy workflows for code only.
Does USourceControl have .gitignore-style file exclusions?
Yes. Projects have an exclusion list that keeps build output, cache folders (like Unreal's Saved/ and Intermediate/, Unity's Library/, Godot's .godot/) out of sync. Sensible defaults are provided per engine.
What file sizes does USourceControl support?
Up to 10 GB per file on every plan, with no repository size penalty for large files. Multi-gigabyte map files, full builds, and video assets all work natively.
Is there a migration path from Git LFS?
Yes — point the desktop app at your existing working copy and make an initial commit. The current state of every file is preserved. Full LFS history import is available on Studio and Enterprise plans.
Give your assets a home that was built for them
Free for solo developers, 50 GB storage, unlimited commits.
Start for free