Your Unity project is too big for Git

Every Unity project starts small. A prototype scene, a few placeholder sprites, maybe a test audio clip. Then the project grows, and so does the repository.

The asset problem nobody warns you about

A fresh Unity project with the default template weighs a few hundred megabytes. By the time you have production-quality textures, animation clips, audio files, prefabs, and a handful of imported packages from the Asset Store, that number can land comfortably in the tens of gigabytes. Some mid-sized projects push past 50 GB. Large studio projects regularly exceed 100 GB.

Git was built to track text. It is excellent at diffing C# scripts line by line, merging branches, and keeping a clean history of code changes. But binary files, the kind that make up the bulk of a Unity project, do not diff well. Every time you update a 200 MB texture atlas or re-export a character mesh, Git stores an entirely new copy of that file in its history. The repository inflates. Clones slow to a crawl. Pushes time out.

Git LFS was supposed to fix this. It replaces large files in the repository with lightweight pointer files and stores the actual data on a separate server. In practice, LFS introduces its own set of headaches. Bandwidth limits on hosted services like GitHub can burn through a free tier in a single push. Locking workflows for binary files are clunky. And if your LFS server goes down or you hit a storage cap, the whole team stalls.

The core tension is simple: Git is a code versioning tool being asked to also be an asset storage platform. Those are two different jobs with different requirements.

What makes Unity assets particularly difficult

Unity projects are heavy on file types that version control systems handle poorly. PSD and TGA texture files can be 50 to 500 MB each. FBX models with embedded animations are often tens of megabytes. Audio files in WAV format, which Unity prefers for import quality, run large. Lightmapping data, baked occlusion, and terrain heightmaps all generate substantial binary output.

There is also the metadata problem. Unity generates .meta files for every single asset. These are small text files, and Git handles them fine individually. But a project with thousands of assets means thousands of .meta files, and any reorganisation of your project folder triggers a cascade of changes that clutter your commit history.

Then there are the Library and Temp folders. Experienced Unity developers know to add these to .gitignore, but the first time a junior team member accidentally commits the Library folder, the repository can jump by several gigabytes in a single commit. Cleaning that out of Git history requires tools like BFG Repo-Cleaner or git filter-branch, neither of which is pleasant to use.

The usual workarounds and why they fall short

Teams have developed various strategies over the years. The most common is Git LFS with a hosted provider. GitHub offers 1 GB of free LFS storage and 1 GB of monthly bandwidth. For a serious Unity project, that is gone in a day. Paid plans help, but the costs scale quickly when your repository holds 40 GB of assets and multiple team members are cloning and pulling regularly.

Some teams split their project into two repositories: one for code, one for assets. This can work, but it adds complexity. Build scripts need to know where to find both halves. New team members need to clone two repositories and set up the correct folder structure. Continuous integration pipelines become more fragile.

Others turn to Perforce (Helix Core) for the entire project. Perforce handles large binary files well and has proper file locking. But it is expensive, complex to administer, and overkill if your codebase is modest and you just need somewhere sensible to keep your assets.

Network-attached storage (NAS) and shared drives are another option. They work for small local teams but fall apart with remote collaborators. Syncing gigabytes over a home internet connection is slow, and there is no built-in versioning or search.

Separating code from assets

The more practical approach is to let each tool do what it is good at. Git handles your C# scripts, shader code, editor scripts, and configuration files. A proper cloud drive handles the large binary assets: textures, models, audio, video reference, concept art, exported builds.

This is where Fabric fits. Fabric is a cloud storage and file management platform, not a game engine plugin or a Git replacement. It does not integrate directly into the Unity editor or manage asset versioning the way Perforce does. What it does is give your large files a proper home in the cloud, accessible from any device, without consuming local storage.

Fabric's cloud drive streams files on demand. Your textures, audio files, reference materials, and exported builds appear on your machine as if they were local, but they live in the cloud. You are not downloading 60 GB of assets to a new laptop just to get started. You are not filling an external SSD because your internal drive ran out of space three months ago.

For developers working on Unity projects, this separation is clean. Your Git repository stays lean, containing only the files that benefit from line-by-line version tracking. Your assets live in Fabric, where they can be browsed, searched, and shared without the overhead of a version control system that was never designed for them.

Finding what you need across thousands of assets

Unity projects accumulate assets faster than anyone can organise them. Six months into development, the project folder is a maze of directories: Assets/Textures/Characters/Hero/v3_final_FINAL, Assets/Audio/SFX/Footsteps_Grass_New, and so on. Finding the right file means either knowing the exact path or spending ten minutes clicking through folders.

Fabric's semantic search lets you describe what you are looking for rather than remembering what you named it. Search for "grass footstep sound effect" and find the file, even if it is named step_outdoor_04.wav. Search for "hero character idle animation" and find the clip, regardless of which subfolder it ended up in.

The platform also offers smart organisation that categorises files by their content. This is useful when you inherit a project from another developer or studio and need to make sense of a folder structure that made sense to someone else six months ago.

Reviewing and sharing assets outside the engine

Not everyone on a game development team works inside the Unity editor. Art directors review texture sheets. Audio designers listen to sound effects in isolation. Producers need to see progress on environment art without launching a project that takes five minutes to open.

Fabric's annotation features let team members draw directly on images and leave timestamped comments on audio and video files. An art director can circle a problem area on a texture, leave a note, and the artist sees it without either of them opening Unity. This is simpler than taking a screenshot, opening it in a separate app, drawing on it, and sending it over Slack.

For sharing assets with external collaborators, freelancers, or publishers, Fabric's publish feature creates shareable pages with link analytics. You can see who viewed the assets and when, which is useful for tracking approvals and feedback from people outside your immediate team.

Working with the rest of your pipeline

Unity development rarely happens in isolation. Concept art comes from Photoshop or Procreate. Models come from Blender or Maya. Audio comes from a DAW. Reference images come from the internet, client briefs, or mood boards. Build outputs go to testers, publishers, or storefronts.

Fabric connects to Google Drive, Dropbox, and other services, so you can pull files from wherever your collaborators already store them. If your concept artist keeps their work in Google Drive and your sound designer uses Dropbox, you can access both through Fabric without asking anyone to change their workflow.

The AI assistant can answer questions across your files, which is helpful when you are trying to remember which version of an asset was approved or where a particular reference image came from. Instead of searching through Slack threads and email chains, you can ask a question and get an answer drawn from your stored files.

What this does not solve

To be clear about the boundaries: Fabric is not a replacement for Git or Perforce when it comes to code versioning. It does not track line-by-line changes to your C# scripts. It does not handle merge conflicts. It does not integrate into Unity's editor as a version control backend.

It also does not provide offline access. If you are working on a plane or in a location without internet, you will need to have the files you need already available locally.

What it does is remove the burden of storing, organising, searching, and sharing the large binary assets that make Unity projects difficult to manage with Git alone. For many creative teams and solo developers, that is the piece that was missing.

If your Git repository has become a source of friction because of large assets, and Perforce feels like too much infrastructure for your team, separating your code from your assets is a practical middle path. Keep Git for what Git does well. Give your assets a proper cloud home.

Frequently asked questions

Can I use Fabric as a replacement for Git LFS?

Fabric is not a Git extension and does not integrate into Git's workflow directly. It is a separate cloud storage platform. You would use it alongside Git: Git for your code, Fabric for your large binary assets like textures, audio, and models. This avoids the bandwidth limits and complexity of Git LFS entirely.

How large can files be in Fabric?

Fabric handles large files comfortably. The kinds of files common in Unity projects, including multi-hundred-megabyte texture atlases, large FBX models, and WAV audio files, are well within what the platform supports. Check the pricing page for current storage tier details.

Does Fabric work on Mac and Windows?

Yes. Fabric has a desktop app for both platforms, as well as a mobile app. Since Unity development happens on both Mac and Windows, this cross-platform support matters.

Can my whole team use Fabric on a Unity project?

Yes. Fabric supports collaboration across teams. Multiple team members can access, search, and annotate shared assets. See the team pricing page for details on team plans.

How does Fabric's cloud streaming work with Unity's asset import pipeline?

Fabric's cloud drive makes files appear local on your machine. When Unity needs to import an asset, the file streams from Fabric's cloud. For the initial import of very large files, this depends on your internet connection speed. Once Unity has imported and cached an asset in its Library folder, subsequent loads use the local cache.

Is my project data secure in Fabric?

Fabric is private and secure with backup. Your files are encrypted and stored securely in the cloud. For game studios working on unannounced projects, this matters.

Can I connect Fabric to my existing Google Drive or Dropbox where assets are already stored?

Yes. Fabric has connections to Google Drive, Dropbox, and other cloud storage services. You can access files from these services through Fabric without moving them manually.

What about Unity's Plastic SCM (Unity Version Control)?

Unity's own version control solution, Plastic SCM, handles large files better than Git. If your team is already using it and happy with it, there may be less need to separate code from assets. Fabric would still be useful as a digital asset management layer for reference materials, concept art, exported builds, and other files that live outside the Unity project itself.

Related pages

• Fabric for developers

• Creative asset management

• Digital asset management

• Fabric for engineering teams

• Fabric for creative teams

• Fabric vs Dropbox

• Fabric vs Google Drive

• Review and approval workflows