There are several version control options available when working on Unity projects. In this article, I’ll review a few of the ones that I have used in the past and discuss the option I finally chose for my current project. If you’re not already using some form of version control for your project, I strongly recommend giving at least one of these a try!
Note: Since there is quite a bit of competition in the version control business, the prices and plans below are likely to change. If you notice something is out of date, please leave a comment, and I’ll be sure to update them.
One might think that the best version control option for a Unity project would be the one that Unity made themselves. Sadly, Unity Collaborate hasn’t had the best track record, and I gave up on it several months ago after a few days of dealing with various issues and long wait times while opening projects. Apparently Unity felt the same way, and it is now deprecated.
In August of 2020, Unity acquired Codice Software, the developers of Plastic SCM. If you’ve never heard of Plastic SCM, it’s certainly worth a look. Its GUI tools (especially its Branch Explorer) are excellent, and its merge tool is arguably better than P4Merge. Plastic is a bit like Perforce in that it has a simplified workflow when using a central server, but it is also capable of working in a more distributed fashion similar to Git. During my use, Plastic has also handled branching much better than Perforce and is again similar to Git.
Note that the comparison table on the Plastic SCM website is a tad bit misleading where it is compared to Git as Git with LFS solves most of the issues shown in the Binary section. There are also several decent (free) GUI clients that solve most of the other issues mentioned. Still, they have some fair points in that Plastic SCM has tried to address most of the issues related to game development from the start without additional configuration. They even have a simplified GUI for non-coders that is certainly a plus as is its built-in integration with the Unity editor (which should only improve now that Unity owns it).
So why am I not using Plastic now? Well, I was until recently, but I finally gave up after having an issue when renaming directories and files in those directories in one commit (something you might see listed as a “Pro” in their comparison table under the Merge section). The last straw was when it simply would not let me commit any of the 35 changes I made. Hopefully, this will get fixed in the future as the only other downside to Plastic for indie developers seems to be its price.
The pricing for Plastic is a bit confusing, but at least some of it is shown on Unity’s website. It’s currently free for up to 3 users with 5GB of cloud storage. Then it is $7 per user per month for additional users. $5 more a month gets you a max of 25GB of cloud storage. It then states that it costs $5 per every 25GB increment, but the examples are a bit odd (45GB for $10, 120GB for $25 ?!?!).
Unfortunately, at some point Codice or Unity decided to require an enterprise license in order to host repositories yourself. For that reason, I don’t recommend Plastic SCM unless you are fine with the cloud option and paying a monthly subscription for teams of more than four or for large storage requirements.
Perforce / Helix Core
Perforce has been around for quite a while and their software has been used by quite a few large game companies. We used it for several years at my previous company, though only for source code as we had our own version control system for non-code assets. In the end, we replaced it with Mercurial and later Git since it was a bit expensive for our uses.
Perforce Helix Core normally requires a connection to a server. There are ways to resolve changes when offline, but the normal flow is that files should be checked out before being edited. The server (P4D) can be run on most platforms and can be hosted on a Virtual Private Server (VPS) such as a Digital Ocean droplet.
The server and repository configuration takes a little bit of time to set up, but the process is fairly straight forward. Unity does offer built-in Perforce integration, but the normal Perforce client application is a bit dated and is one of my least favorite to use. Branching support was pretty frustrating in the past in Perforce. Their newer version of branching called “streams” improved on this some, but I still find dealing with branches in Git easier and less aggravating.
Perforce Helix Core is free for 5 users. Unfortunately, their pricing is not made available publicly, and it is reported to currently be a few hundred dollars to purchase per user with a percentage of that for annual renewals. The fact that they refuse to list their pricing was enough for me to avoid it should they decide to further restrict the number of free users down the road. Although I’m not a huge fan of Perforce for version control, I am a fan of their free file diff and merge tool P4Merge.
And finally, there’s Git. It might be obvious from the list above, but Git was not my first choice. Sure it’s free and open-source, and I’d used it quite a bit in the past on more code-based projects, but it wasn’t until more recently that Git LFS (Large File Storage) support was stable and widespread enough to make Git a reasonable option for large game projects that needed to store large numbers of binary asset files.
Don’t get me wrong. It’s not all sunshine and rainbows with Git and there are still a few LFS improvements that I’d like to see happen that I think would benefit those working under hosting size and bandwidth constraints. But if money is a concern, and it usually is for indie developers, then it’s hard to beat free. It’s also hard to beat the amount of support that is available as everyone seems to use Git at least partially these days.
The first big question that I had to answer when switching to Git was, “Where should I host my repository?” There are many choices for this and the prices can vary quite a bit, so I’ll cover some of the popular ones that I looked at initially.
GitHub is pretty much synonymous with Git at this point. According to its website it now hosts over 100 million repositories, so it’s safe to say that it is fairly well-proven. In addition to hosting Git repositories for projects, it also offers support for issue tracking, pull requests, and a wiki.
A little known fact about the GitHub Free plan is that you have access to free public and private repositories with unlimited collaborators (often referred to as users on competing products).
With this change the major concern for small teams will likely be storage and bandwidth requirements. These appear to be limited to 1GB of LFS storage and 1GB of bandwidth. The bandwidth limit is pretty terrible as repository clones will count against it and even a small project with a few people will use most of it fairly quickly. Also keep in mind that each commit of a LFS file counts against the storage limit.
Luckily, GitHub offers a way to purchase additional LFS storage and bandwidth. An additional 50 GB of storage and bandwidth can be purchased for $5 per month and multiple purchases can be made to increase the limit even more.
I think I might have gone with GitHub if it wasn’t for the somewhat (silly) low bandwidth limits. Worrying about how many times other developers and artists may clone or pull files from a repository seemed like something that I’d rather avoid.
GitLab offers many of the same features that GitHub offers, in addition to a bit more advanced issue tracking and Kanban boards. Git LFS now appears to be included on their free plan, and it has a 5GB storage limit and 10GB transfer limit per month with is nicer than GitLab’s free plan. Sadly, the free plan does have a 5 user limit though.
To support more users on a project, everyone appears to need to upgrade to their Premium plan which is currently $19 per month per user. This does have the benefit of increasing the storage limit to 50GB and the transfer limit to 100GB per month.
Sadly, the purchase of storage and transfer as an addon is a somewhat insane: $60 for only 10GB more storage and 20GB more bandwidth, so you may be better off starting with the premium plan if you have just a few users.
Bitbucket is made by Atlassian and has a lot to offer as well. They have a free tier for small teams of up to 5 users with 1GB of storage. Their standard tier costs only $3/user/month and comes with 5GB of storage. Additional storage can be purchased for a very reasonable $10/month for 100GB of storage (even for the free tier).
Sadly if you’re looking for file locking support, Bitbucket’s cloud service does not yet support it despite this request from over two years ago. If file locking is important to your project, be sure to voice your opinion on this task as that’s all that seems to be lacking for many game teams.
DevOps pricing is pretty reasonable, especially for small teams. It’s free for the first 5 users and $6/month/user for additional users, and it includes unlimited private Git repositories. Sizes limits for the actual repository seem to be 10GB, but DevOps offers Git LFS support with file locking and LFS storage and transfer does not appear to be limited at this time.
Self Hosting (Gitea)
Finally, there’s self hosting, be it on a local server machine or in the cloud on a VPS. Some of the above cloud-hosted services also have self-hosting options, but most still charge a price per user.
For a free, cross-platform, open source GitHub alternative that you can run yourself, I strongly recommend Gitea. Gitea is written in Go and is distributed as a single executable file per platform. Configuration is amazingly painless and in just a couple of minutes, I was able to setup a new repository and push my project to it. It has Git LFS support (including file locking) and features a wiki and issue tracking. Best of all it runs well with minimal system resources.
The downside to this route is obviously the extra work and maintenance required to setup and secure a server, but the payoff is the cost (for Gitea at least) in not having to pay per user. A $5-6/month VPS at Linode or Digital Ocean or comes with 25GB of SSD storage and up to 1TB of bandwidth (only outgoing is tracked). If the project grows bigger, the VPS can be upgrade to 50GB of storage and 2TB of bandwidth for $10-12/month. Both offer additional storage at reasonable prices.
Picking a Version Control Option for Unity Projects
After bouncing around a few times between the options above, I finally decided to go with Git. The price is right, and the number of hosting options and clients available is pretty hard to beat. For cloud hosting I decided to go with Azure DevOps in addition to running Gitea on my home server (an Intel i3 machine with mirrored 1TB drives for repository storage) since Git makes it easy to push changes to both. Should Microsoft change their free tier in the future, I’ll likely setup a VPS on Linode and move my Gitea instance there.
What about Task Tracking?
For task tracking I’m currently using Quire. I really enjoy how clean it looks and how easy it is to create and work with task hierarchies. Their is also a Kanban board to make organizing and shuffling tasks around easier. Most importantly, there are keyboard shortcuts for almost everything! It’s currently free, though it does appear they will eventually have paid tiers as well. Depending on how that goes I may switch entirely to Gitea as its issue tracking is still more than enough for what I need.
What about a Wiki?
I have yet to find a Wiki that I really enjoy using, mostly due to annoying (no) organization, quick searching, and lack of decent WYSIWYG editing. I tend to find it much easier to remember where something is in a document if I’m editing the final document. So, for now, I use OneNote (2016 Desktop) for everything as I haven’t been that thrilled with Microsoft’s (lack of) direction with the latest version and the number of bugs and missing features that it has compared to the 2016 version.
Since Gitea’s wiki is implemented as a secondary Git repository, I have also been testing using it along with Typora (a WYSIWYG markdown editor) – which I have been very impressed with so far.
What about a Git client?
In the next article I’ll discuss which Git clients I’m using, and in the following article, I’ll jump into configuring Git LFS to deal with the large variety of binary assets found in game development.