Getting Serious About Version Control for UE with Textil

This article is about Textil, a tool I've been developing to pursue my vision of what version control for Unreal Engine projects should be. As someone who has suffered through the version control challenges that UE projects face, I decided to build a tool that addresses these issues head-on.

Version Control Around UE​

The version control landscape around Unreal Engine is excessively complex.

Large studios with deep pockets might be able to throw money at the problem, but for indie projects and solo developers who just want "reasonably comfortable version control," the list of things to consider quickly becomes overwhelming. Worse, solving these problems often requires deep knowledge of UE project structure and version control tools.

I consider this a serious issue. Having worked on projects in web development, infrastructure, and tooling outside the games industry, I can say it's quite rare to have to struggle this much just to manage a project. As a result, UE development teams tend to gravitate toward legacy solutions—sacrificing flexibility, convenience, and communication efficiency in favor of stability.

The Money Solution​

Take Perforce, for example. It's stable and proven, but licensing isn't cheap, and you need to set up and maintain a server. It's not suited for distributed development, and branching isn't as casual as it is with Git. You often end up with a workflow that's simple in some ways but restrictive: "everyone connects to the same server and works on the same branch."

The Git Route​

On the other hand, choosing Git brings its own set of problems.

Git itself is an excellent tool. It's the most widely used VCS in the world, and outside of UE and the broader games industry, it's hard to find a project that uses anything else. The ecosystem benefits are enormous—modern project management tools and CI/CD workflows all support Git first.

However, Git's compatibility with UE has some challenges:

• Binary files can't be merged
  • Binary files like .uasset can't be merged. If two people edit the same file, someone's changes have to be thrown away. Git LFS helps with large files, but it comes with its own complexity: .gitattributes configuration, ensuring every team member has LFS installed, transfer bandwidth costs, limitations of the lock feature... "just using Git" is never quite that simple.
• Limitations of file locking
  • Git LFS's lock feature (git lfs lock) has a fundamental compatibility issue with branch-based development. Even if a lock is available, the file might already be edited on another branch. You only discover the conflict when you try to merge.
• Transfer costs
  • If you use Git, you probably want to manage it on GitHub. But here's where the LFS billing problem hits. GitHub charges not only for storage but also for LFS transfer bandwidth. Between clones and frequent CI/CD transfers, even small projects can easily rack up hundreds of dollars a month.
• Git for artists
  • Git is second nature for engineers, but not so much for artists. Command-line operations, concepts like "staging," "commit," and "push," and the inability to see what changed in a .uasset from a text diff. GUI tools like TortoiseGit and SourceTree exist, but they're designed for managing text files.

No Matter What You Choose​

There are other options like Plastic SCM (now Unity Version Control). But ultimately, no matter what you choose, you can't avoid the pain that comes from managing something as unique as a UE project.

Textil: A Solution​

I mentioned earlier that I've "worked on projects in web development, infrastructure, and tooling." I also have some knowledge of UE internals, and I know the pain points of UE project workflows firsthand.

...So why not build a tool and platform that solves these problems?

That's why we started developing Textil. It's a version control tool built on Git that tackles the challenges unique to UE projects head-on. It connects directly to existing GitHub repositories, maintains Git workflows, and aims to eliminate the pain of binary file management—especially .uasset files.

• Branch-safe file locking
• Faster file transfer than Git LFS
• Cloud storage with free transfer bandwidth—you only pay for storage
• .uasset preview and diff visualization
• Deep integration with Unreal Engine
• etc...

"Git's freedom with reliable binary management, for every Unreal Engine developer." That's the Textil concept.

Before the Details​

First, take a look at these screens.

.uasset Preview​

You can view Blueprint graphs. Materials too, and Control Rigs. (Switch between images using the tabs)

Material Instance parameters, Texture assets, and Data Assets work the same way.

By leveraging the engine's reflection system, even assets without dedicated preview support can have their internal data inspected to some degree.

And You Can View Diffs​

It's not just previews. Diff visualization is also supported.

It's more powerful than the engine's standard Blueprint diff tool. It highlights only the nodes that changed and can filter out cosmetic-only changes that don't affect logic.

OFPA Support​

When One File Per Actor (OFPA) is enabled on a level, each Actor is saved as a separate .uasset file. Since file names become hash values, regular Git clients can't make sense of them.

Textil parses the file contents and displays the Actor name. In the future, we plan to trace back to the source Actor asset for even better display.

By integrating closely with the engine—understanding reflection and .uasset files—we aim to bring comfortable, diff-based version control to UE development.

Tackling the Binary Management Problem​

But the problem isn't just that .uasset files are hard to work with outside of UE. Let's revisit the challenges.

File Locking​

File locking is a mechanism to avoid binary conflicts by "declaring before editing." Git LFS has a lock feature (git lfs lock), but as mentioned earlier, it has a fundamental compatibility issue with branch-based development.

Let's look at a concrete example. Suppose Alice edits Hero.uasset on the main branch, commits, and releases the lock. Then Bob tries to lock the same file on a feature branch. The lock is available, so he gets it. Bob edits and commits without knowing about Alice's changes. When he tries to merge feature into main... conflict. Someone's changes have to be thrown away.

Traditional locking only looks at "who currently holds the lock."

Large Volume × Large Size Binary File Transfer​

People sometimes say "Git LFS is slow." Indeed, compared to file transfers in Plastic SCM and similar tools, Git LFS Push/Pull can be slower even at the same connection speed. Why is that?

One reason is that Git LFS goes through Git's Filter mechanism. There's per-file communication between the Git process and the LFS process, so overhead accumulates as file count increases. Since upload/download processing only runs when invoked by Git's Filter, the LFS side can't control the distribution or scheduling of binary file processing. This leads to idle bandwidth time when files aren't being transferred.

Additionally, some servers have naively implemented LFS with HTTP/1.1 connections. This means only one request per connection, requiring repeated connection establishment and teardown for large numbers of files. Transfer layer issues like these are actually part of the problem.

And as mentioned, GitHub LFS charges based on transfer bandwidth. It's not just a speed issue but a cost concern as well.

Textil Cloud​

To solve these problems, Textil provides Textil Cloud, which communicates with clients via a proprietary protocol.

Locking​

We solve this by tracking file "lineage." When requesting a lock, we verify whether the requester has the latest state—if not, the request is rejected. In the earlier example, when Bob tries to lock, he'd be told "You haven't incorporated Alice's changes." Once Bob runs git merge main to incorporate Alice's changes and tries again, it succeeds. "If you can get the lock, you can safely edit" is guaranteed.

By the way, this verification uses file content hashes, so it correctly tracks files even when commit history is rewritten by squash merge or rebase. Lock state is shared in real-time via WebSocket, so when someone acquires a lock, everyone is notified immediately. See the documentation for details.

File Transfer​

We bypass the Filter mechanism and process files through our own pipeline. We use QUIC as the protocol, allowing multiple files to stream over a single connection and fully utilize available bandwidth. Transfers can resume from where they left off if interrupted, so unreliable connections are not a problem.

And here's the best part: Textil Cloud has free transfer bandwidth. You only pay for storage. And even storage pricing is set quite low. No matter how many times CI/CD clones or how many team members you add, you don't have to worry about transfer costs.

Textil Cloud × GitHub​

"Wait, does using Textil mean I have to use a proprietary cloud? Can't I use GitHub?"

Don't worry. That's not the case.

Textil Cloud only handles fast binary file transfer/storage and lock management. You can manage your project on GitHub while offloading just the binaries to Textil Cloud. This way, you stay in the Git ecosystem while using Textil's binary management system.

We also guarantee compatibility with standard Git LFS. If you don't need the high-speed transfer or lock system, you can use just GitHub's LFS (but keep in mind—once your project size grows a bit and transfers add up, Textil Cloud is probably, no, definitely cheaper than GitHub LFS).

Security​

Some may have security concerns about entrusting project data, lock information, and member data to an external service. Especially in the games industry, leaking pre-release assets can be catastrophic. We understand that concern.

Typical multi-tenant services store multiple organizations' data in a single storage or database, using software-level access control for separation. If you've implemented such systems, you may be familiar with this architecture. However, this approach carries some risk—if there's a bug in the application, there's a non-zero chance of accessing another organization's data.

With Textil Cloud, when you create an organization, dedicated storage buckets, databases, and processing workers are provisioned exclusively for that organization. All organization-specific data is stored in these dedicated resources, and access to organization resources is routed through an upper-level routing system. In other words, data storage and processing locations are isolated from other organizations from the start—so even if there were a bug in our implementation, unauthorized users accessing another organization's data is structurally impossible at the infrastructure level.

Textil CLI​

Sharp-eyed readers might be thinking, "If you're using a proprietary protocol, doesn't that mean you can only access the repository from Textil's app when using Textil Cloud?"

No need to worry about that either.

We develop all of Textil's functionality as a library. The GUI application is just one implementation built on that library. And we provide the Textil CLI, offering the exact same functionality on the command line, alongside the GUI.

What this means is that you can call Textil CLI from CI/CD pipelines to access data on Textil Cloud with authentication and proprietary protocol handling already taken care of. Whether you use GitHub Actions, Jenkins, or your preferred CI environment, you get the benefits of Textil.

Unreal Editor Plugin​

For artists and level designers, being able to manage version control without leaving the editor is essential.

Textil also provides a dedicated Source Control plugin for Unreal Editor. You can check file lock status in real-time within the editor and acquire or release locks directly from the Content Browser. When someone acquires a lock on another machine, it's immediately reflected in your editor.

Making Textil's features available within your usual workflow without opening external tools—this is another part of our effort to create a tool that's truly usable for UE developers.

Of course, Textil's UE plugin doesn't just operate through UE's Source Control feature. By working in tandem with the Textil application, we plan to offer features like jumping from Textil to UE content, or opening Textil's diff view from the editor. We're aiming for a seamless experience moving between Textil and Unreal Editor.

Closed Beta Announcement​

Textil is currently running a closed beta.

There's still a lot of development underway, and many features that exist only as concepts haven't been covered in this article. Honestly, there are still plenty of rough edges—but that's exactly why we want feedback from people who are actively developing UE projects.

"We're struggling with this in our team's UE development." "This feature would be great to have." "This part is hard to use." We'd love to hear your thoughts. We want to build something truly useful for UE developers, together with you.

• Textil Official Website: textil.dev
• Closed Beta Application: textil.dev/apply

Conclusion​

Version control for UE × Git has long been accepted as "just the way things are." LFS configuration is a pain, binaries conflict, branch switching is heavy.

But it doesn't have to be that way. It should be possible to maintain Git's flexibility while making binary file management more comfortable. If we can achieve that, modern version control and CI/CD ecosystems can benefit the UE community and improve our development experience. Textil pursues that possibility.

This tool is still very much in development, but we'd love to make it better together with those who share these challenges.

Merry Christmas 🎁