null
April 11, 2019

Git vs. Perforce: How to Choose (and When to Use Both)

Git at Scale
Version Control

There is plenty of debate on using Git vs. Perforce for source code management. Teams are looking for the ideal solution to make developers happy and support DevOps. So decision-makers have a lot to consider.

Here, we break down the differences between Git and Perforce — and how you can use these tools together.

What’s the Difference Between Git and Perforce?

Different teams have different needs. Git might be a good choice for one team; Perforce might be the right version control for another.

Native, open-source Git can work well. This is especially true for code-only projects with a small group of developers and fast release cycles. One example is website development.

Using enterprise version control from Perforce is a good option, too. This is especially true for large teams with complex projects incorporating various digital assets. For example, with game development and semiconductor companies, Perforce solutions help to integrate all digital assets –– like binaries and design files –– and keep them safe.

Perforce vs. Git Comparison

Let’s review some of the key differences.

Centralized vs. Distributed Model

Git Is Distributed

With a distributed Git model, developers download source code –– along with a full version history –– to their machine. Then they are able to make changes locally. This makes local commits, diffs, and merges fast.

But a team of developers –– each of whom has their own copy of the repository –– need to coordinate sharing of changes. The question then is, who's repository is the master? Your company may also have security concerns. Each developer having a copy of the repository on their machine can be difficult to manage. That’s why more and more teams today are using a centralized Git model. Changes intended to become part of the project are submitted as a pull or merge request to a master branch. This is done to a dedicated Git server, rather than to one particular developer’s workstation.

Git permissions are assigned at the repo level. Therefore, teams with security requirements typically break their projects into several repositories. This ensures developers only have access to the repositories they need. This makes auditing easier. But once a project is broken up, teams need to deal with cross-repository dependencies.

Perforce Is Centralized

Helix Core –– version control from Perforce –– has a centralized model. Storing everything in one place ensures developers always have the latest version. Developers, no matter where they are located, commit all their changes to a central server. Having one copy of a project creates a single source of truth across your enterprise. This also improves communication because work in progress is easily visible to other team members. Whereas the status of Git work in progress is only stored in a local repository.

A centralized model makes code collaboration and code reuse much easier. And it assures auditability and traceability. Even though Helix Core is centralized, it securely supports remote sites through replica and proxy servers. This dramatically improves performance because most actions are done locally.

Performance

When it comes to performance, teams are often surprised when comparing Git vs. Perforce. 

Where Git Is Faster

Local commits, diffs, and merges can be faster with Git. But many developers pushing and pulling repos slows down performance and decreases productivity.

Where Perforce Is Faster

Helix Core was built for speed and scale. It can handle millions of transactions a day, billions of files, and petabytes of storage. Developers can quickly and easily see whether or not they have the latest version of a file on their workstation. Plus, it handles large binary files with exclusive locking. This prevents team members stepping on each other’s work.

With Perforce Federated Architecture, remote teams experience local-speed performance for large clone/pull/build operations. This can decrease much of the WAN wait with traditional Git.

Managing Large Files/Binaries

Large files and binary artifacts are part of development. They can be the result of builds and inputs into testing. But for some industries, like game development, they are integral to your whole process. You need to be able to combine both artist and developer's work into the final product.

Git Offers LFS

Today, Git attempts to addresses this with Git LFS. But most large teams store their large binary assets in an artifact repository tool, like Nexus or Artifactory. This means you no longer have a single source of truth. These additional tools also complicate your build pipeline.

Perforce Stores It All in One Repository

In Helix Core, artifacts are stored alongside your source code and other non-code assets. These artifacts can be checked in as part of the same changelist as your related source code. Having everything in one central server makes workflows simpler. And your admins don’t need to manage additional licenses and integrations.

Branching

Both Git and Perforce offer lightweight branching. Although, both track branching differently.

Git Branches

In Git, when a branch is created, you can instantly start work on the local new branch. After you’ve made your additions and changes, and you are ready to commit, you can either merge or rebase the history. But merging to your local copy of the master branch is not the same as pushing your changes to the central repository. 

If multiple developers were working on the same files when you push your changes, merge conflicts can arise. This is why it is always important to fetch the latest changes from the server before merging. But if you have hundreds of developers working on a project in Git, this can be time-consuming. 

And if you have cross repository dependencies, then you need to coordinate merge conflicts across repos. This can be tricky. it gets harder as your team or the number of repos grows.

Perforce Branches 

In Helix Core, branches are done at the file hierarchy level. Your team members can pick and choose specific files to checkout and submit back into the repository. Exclusive checkouts give developers visibility into what other people are working on. And with granular permissions down to the file level, admins can keep their most important files protected. 

Perforce Streams –– our way to branch and merge –– simplifies workspace set up and helps guide teams. Developers can easily switch between streams (branches) and it is easy to see how changes are propagated. As with Git, when submitting changes to the master stream/branch, you can still get conflicts. These are generally easily managed. The advantage with Helix Core is the visibility into work in progress, and the advanced notice for potential merge conflicts.

In addition, the scalability of Helix Core allows developers to submit a potentially large changelist, affecting multiple components, in a single action. This can significantly reduce issues with code dependencies. These could potentially be cross repository dependencies in Git. Also, these changes can be easily tracked and managed.

So Why Use Git?

There are many good reasons why so many teams use Git.

As we described, it solves the most basic version control problem. It allows developers to simultaneously work on the same code, without duplicating effort.

It’s fast for local operations.  And Git is often first version control system (VCS) developers use in universities. Most developers know frequently-used Git commands, such as clone, commit, and push. Plus, it’s free!

The Rise of Git for Large Enterprises

Over the last few years, numerous commercial companies have sprung to life with the mission of monetizing open source software. GitHub, GitLab, and Atlassian have done this with Git. They’ve added nice user interfaces, code review workflows, management capabilities for multiple repositories, and pipeline integrations to Git. 

Each of these Git providers are far more popular with individual, free users than paying enterprise customers.

GitHub, GitLab, and Atlassian don’t always work for enterprise software development teams. Git’s architecture has proven difficult to scale in that environment.

When to Use Perforce (Helix Core)

Perforce is the right version control system when you have:

  • Large code bases.
  • Non-code assets, like binaries or graphics.
  • Code dependencies, particularly across components.
  • Extensive code reuse, such as artifacts.
  • Large, geographically diverse teams.

This is where Perforce excels. This is because our version control was designed for large teams with large codebases and complex development environments.

 

Learn More About Git vs. SVN >>

 

Compare SVN vs. Perforce >>

 

Git vs. Perforce: No Choice Required

Companies need the scalable benefits Perforce provides. Now you can get those benefits — and use Git, too.

The solution to this complex issue is not deciding on Perforce vs. Git. It’s using both together with Helix4Git.

Helix4Git natively stores Git repos, with the speed and reliability of the Perforce Helix Core server. This solution is unique in the industry and supports your DevOps evolution.

Perforce for Git Users: Helix4Git

Your developers can still use Git commands like merge and rebase, create submodules, you name it! This is because they have access to either solution — without any changes to their workflow or environment.

In fact, you can add Helix4Git even if you are in the middle of a project. It’s that seamless. You can store your Git repos natively in Helix Core, which also supports Git LFS artifacts.

A central, single source of truth streamlines Continuous Integration/Continuous Delivery (CI/CD).  

Helix4Git makes Git faster — 80% faster with 18% less storage.

This means teams get the feedback they need, quicker. Developers, release managers, and CI/CD teams get more hours back in their lives.

Review Helix4Git FAQs >>

 

Get Started With Helix4Git

See for yourself why Helix4Git is a smart choice that squashes the Perforce vs. Git debate.

Perforce + Git