State of UE4 SCM: Git vs. Perforce vs. Plastic
Use Perforce, or Git LFS if your project is small
Note: I have edited this article multiple times, as new experiences/information/updates have come up
The problem with SCM (source control management) in UE4:
Blueprints, and most assets are binary files which cannot be merged. It is possible to diff BP’s however you can only select one revision or the other.
The inability to selectively merge means that if two people work on the same BP, only one of those versions can be accepted.
It may be possible to copy and paste nodes from one version to the other, but this is inevitably an error-prone process, and figuring out what needs to be merged over manually is not ideal.
The solution to this problem is to “lock” the file while working on it. If you haven’t heard of this concept, it’s probably because you use Git, which only supports this concept in Git LFS.
All 3 options can work, and they all have plugins for UE4.
TL;DR: Perforce is what Epic uses, so it’s best supported. If you want to reduce risk, use that. If you want to be a benevolent developer, contribute to the Git LFS UE4 plugin.
Git w/ LFS (Large File Support)
I initially had some issues migrating my project to Git LFS, but the most significant and mysterious of them was resolved by updating my Git Bash client, which also upgraded Git LFS from 2.5.1 to 2.6.1. I wasn’t able to push my repo until doing this.
Git LFS is reported to have some stability issues when it comes to working with really large repos. This was enough to deter me from committing a big project to it, however I would love to hear if you are using it successfully.
The in-editor support for Git LFS is not quite as good as Perforce, files don’t seem to request getting checked out right away, and I wasn’t sure what “sync” meant in the context of Git. Of course, the Git LFS plugin is open source, so anyone could go and fix these issues.
Perhaps my biggest issue was just that everything seemed to take longer in the editor, something about the Git commands used for the plugin just is slow. This seems solvable, and I would vastly prefer to use Git mostly because there is so much CI/CD tooling based around it.
Plastic SCM
Upfront Plastic looks quite good, and I actually recommended it when I initially wrote this article. Locks seem to work, and it supports porting over your Git repo. There is a UE4 plugin for it, which checks out (locks) files as you modify them.
I had issues in one case where our project was too big (~40GB) for the server we were using with Plastic. Unfortunately there wasn’t much indication of this except that all sorts of stuff just didn’t work very well.
In a later project I was part of, we used Plastic and it basically worked, however we found there to be pretty significant restrictions with Cloud Edition that made it impossible to set up a push notifier (send a message to Discord/Slack/etc. when changes are pushed).
My biggest reservation with regards to Plastic is that the company seems to value appearances over functionality. The UI is more “modern” but lots of important options are underdocumented, and certain features are just missing. The forums had a lot of disappointing questions about pretty serious topics.
One of the main selling points of Plastic SCM is supposed to be making DevOps easier to set up. In my experience, this is the hardest platform to do anything DevOps related with.
Perforce (Helix Core)
Epic uses Perforce (Helix Core) internally, “for historic reasons”. Perforce supports locking, but you must host it yourself (no GitHub/BitBucket/etc.). Assembla can host Perforce, but they don’t seem to have a free version, and the paid version costs hundreds of dollars per year per user.
There’s not a lot of concise material out there about how to setup Perforce (or p4 for short), but it actually isn’t terribly hard. It can be setup on your own computer/server by basically following the install prompts. The best resource for getting it hosted somewhere I found was this Youtube series.
Simply put the Perforce integration for UE4 is still the only option that has proven to be stable. The P4VS plugin for VS is quite handy and allows you to do Git-style merge flows for source code while getting the locking benefits for binary files.
CI/CD with Perforce is hard mostly because it is not nearly as popular as Git. So setting up the Jenkins plugin for example is not perfectly streamlined, I had to spend some time getting the right Java version and fighting other small errors or trying to recall the difference between a “Port” and a “Host” (in Perforce, a port is something like 123.123.123:8080).
Additionally Perforce has its own GitHub style code review/bug tracking platform called Swarm. We tried this at one point, however I had a very hard time and eventually gave up on getting email notifications to work properly (maybe I just had SMTP setup wrong?). What I really wanted were Discord notifications anyway, which of course weren’t included by default.
Code review without notifications is not very helpful so we didn’t get to really test this. I’m considering trying out a sort of hybrid Git/Perforce setup where changes are mirrored to a git repo, but that’s to be determined.
