When you are coding, particularly if multiple collaborators are involved, it is important that you have some sort of version control.
Without version control, it can be exceedingly tough to track what each collaborator on a project has done, or perhaps roll back code to an older version should something 'go wrong'.
There are a lot of services that offer version control. Two of the most popular are Git and Perforce. In fact, ask any major developer which system they use for their version control, and we guarantee it will be one of them.
So, what is the difference between the two? Which one is right for you? Find out as we compare Git vs Perforce.
Check out this article on the Best Game Engine
Git vs Perforce: A Comparison Chart
As with all of our comparisons, we want to start with a quick comparison chart that should highlight the differences between Git and Perforce.
This should make the start of the Git vs Perforce comparison a bit easier, but we do urge you to read on where you can get a much more complete overview of the two systems.
| Feature | Git | Perforce |
| Pricing | Free | Paid, depending on business needs. |
| Model | Distributed | Centralized |
| User Interface / Ease of Use | Multiple user interfaces available, but it can be tricky to use Git | Just one UI. Using Perforce is a bit more intuitive than Git. |
| Branching | Limited branching. Merging code can be difficult. | Branching is done at a file level, making branching much easier. |
| File Locking | Limited to no support | Can lock individual files |
| Non-Code Asset Handling | Limited to no support | Supports non-code assets |
| Scaleability | Not great for larger projects | Often selected by game developers for the ability to handle larger code bases. |
Pricing
Git is free. It is open-source software. Perforce is free for up to 5 users, but larger teams must pay. The cost can be quite considerable for larger businesses.
Of course, Git is only going to be free if you self-host it, which isn't really used when you are collaborating. Depending on your code base, hosting could cost hundreds of dollars per month. Although, that is the case with Perforce cloud hosting too.
If you are working on solo projects and just need a bit of version control on your computer, then Git is fine.
Self-Hosting vs Cloud Hosting
Both Git and Perforce have self and cloud hosting.
Git cloud hosting is considerably cheaper than Perforce because you do not have to pay for the license to the software.
This is why many smaller collaborative coders opt for GIt. It is cheaper. Significantly cheaper.
Model
This is where we start to see the major difference between Git and Perforce. Git is what is known as a distributed model, while Perforce is a centralized model.
With Git, all versions of the code are downloaded to a person's computer. All of them. This means that the user can make their changes to code, merge, etc. independent of anybody else. Once the changes have been made, they will be pushed to the repository.
Perforce has a centralized model. This means only the relevant files are downloaded to the user's computer. The changes/merges, etc. are made and then re-uploaded to the centralized server.
There are some major pros/cons to how each of these methods works.
With Git, there is the risk that it can get confusing about what the master copy of a file is. If two coders are working on a file and upload them both, which should be the main one in the eyes of the code repository?
It isn't a massive problem if you are a solo coder, but can get confusing when you have a ton of people working on files.
Perforce is just slower. While it doesn't have the 'master' issue with the code (as there will only be one copy), it makes merging, downloading code, etc. much harder. You also need a connection to the internet (more on that soon).
If you want to learn more about Git version Control check out this complete course - Link Here
User Interface
Git has a UI, several in fact. The base Git download is awful to use, but if you tinker with a few downloadable UIs, you can get it looking exactly how you want. However, this tinkering does require time and effort, and it may be confusing for people that don't have a clue what they are doing.
Perforce, on the other hand, has a decent-looking UI that is easy to navigate around. Although, you are pretty much stuck with what you have. You can't change it too much. Probably not an issue for most people, though.
Branching Capabilities
Branching is another major area of difference when it comes to Git vs Perforce. We actually touched upon branching a little bit beforehand when we discussed how the models work.
With Git, you can make a new branch of code whenever you want. That isn't an issue. Once you make a new branch, you can start working on the new code right away.
This is fantastic if you are working on a solo project, but if you have dozens of people making their individual branches, it can make code merges much more difficult when everybody tries to re-upload at once.
Every time you want to upload a new file to the server, you have to fetch any changes, and this just takes way too long for major projects.
Perforce is different. Only one person can be working on a specific file at any one time, and only one file. No major merging of the code bases. Since only one person can work on a file (and you will always know who is working on that file), there can be no conflicts with any code merges. This is important for big companies.
File Locking
Git doesn't really have file locking. It has something that sort of works when it comes to file locking, but rarely. If file locking is important, then we absolutely would not recommend that you use Git.
Perforce offers file locking by default. Whenever a file is 'checked out' for editing, it is locked. However, other files can be locked off by admins so they cannot be used or accessed by those without permission.
Speed (Including Scaling)
With Git, working on your files at a local level with mergers, diffs, etc. is much faster. However, because every file needs to be synced with the central code repository, the overall process is much slower.
Perforce is slower with mergers, diffs, because you have to check out each individual file that you want to work on. However, the speed of syncing the code repository is much, much faster.
Perforce also deals with larger code bases much easier. It can handle millions and millions of changes per day without faltering. Once you scale Git up to larger projects, it isn't as great.
In fact, most companies that work on larger coding projects will probably avoid using it. You rarely see Git being used by major game developers, for instance.
Online/Offline Usage
To put it in simple terms, Git can be used offline, while Perforce cannot.
Non-Code Assets
While there are some ways to store non-code assets alongside your code with Git, it involves jumping through a lot of hoops and the process isn't as stable.
With Perforce, you can store all non-code assets next to your code base with ease. This makes it easier for coders to refer to them. it also limits the number of services that you need. As you can probably imagine, Perforce is a major player in the game development industry for this reason.
Ability To Move To New Systems
When you use Perforce, you are locked into using Perforce services. This can get costly. With Git, you have much more of an ability to 'move around'. Use different hosting services, tinker with plugins, etc.
In our opinion, Git is much more flexible. Although, most people probably don't need that flexibility.
Git vs Perforce: Which System Is Right For You?
This is actually the trickiest question to answer, and we have written a lot of comparisons. Both Git and Perforce are wonderful systems. So much so that even Perforce recommends that there are some situations where Git may be a better option than their software.
So, you should be fine with either of them. Most people will opt for Git because it can be used for 'free', while Perforce is the domain of the larger companies.
Perforce tends to work a lot better when you have a massive code base, or you are working with a lot of non-code assets. However, for most smaller projects, Git should be 100% fine.