Different problems, different solutions

Perforce was released in 1995 - a decade before Git or Mercurial. It targets a particular shape of problem: large, often binary content; highly regulated workflows; teams that need fine-grained access control and exclusive locks; projects measured in terabytes, not gigabytes. Game studios, film VFX houses, hardware design firms, and aerospace companies are typical users.

Architecture

Perforce is centralised, like SVN, but engineered for scale far beyond SVN's typical use. Clients have minimal local state; the server is the source of truth and the locus of all operations. The protocol and storage are optimised for binary blobs, exclusive checkout, and per-path security.

Git is distributed - every clone is a full repository. The economic assumptions diverge: Git assumes cheap local clones; Perforce assumes expensive content that must be centrally controlled.

What Perforce does brilliantly

• File locking - exclusive checkouts prevent concurrent edits on unmergeable binaries.
• Streams - declarative branching with strong relationships between mainline, development, and release streams.
• Per-path security - access control granular to single files, with audit trails.
• Massive repos - terabytes of content, hundreds of thousands of files, no client-side bloat.
• Atomic submits across files - changelists guarantee all-or-nothing commits.
• Mature integration - decades of experience with build farms, IDE plugins, render pipelines.

What Git does brilliantly

• Cheap branching and merging for code-heavy work.
• Distributed history - offline work, fast local operations, clone-anywhere.
• Massive open-source ecosystem - GitHub, CI/CD, security tools.
• Integration with modern code review and PR-driven workflows.
• Cost - Git is free; Perforce is licensed.

Day-to-day commands

# Perforce
p4 sync                 # update working copy
p4 edit file.txt         # check out for edit (acquire lock if exclusive)
p4 submit -d "Edit"      # commit to server
p4 changes               # list changelists

# Git
git pull
git add file.txt
git commit -m "Edit"
git push
git log

Branching

Perforce streams model is more declarative than Git branches:

p4 stream -P main //my-depot/release
p4 stream -P main //my-depot/feature-x

Streams encode their relationship to a parent and the merge direction. Git branches are unstructured pointers - the team agrees socially on parent relationships.

Locking

Perforce's exclusive lock is the killer feature for binary-heavy projects:

p4 edit -t binary+l character.fbx
# Now the file is locked; no one else can edit it

Git LFS supports locking but it is bolted on; Perforce treats it as fundamental.

Use cases where Perforce wins

• Game development with terabytes of art assets.
• VFX studios with massive render outputs and source meshes.
• Hardware design with binary CAD files.
• Regulated industries needing fine-grained audit trails.

Use cases where Git wins

• Open source software.
• Web and mobile app development.
• Library and SDK development.
• Anywhere the workflow is "branch, PR, merge".

Hybrid approaches

Many large game studios run Git for engine code (small, mergeable, distributed-friendly) and Perforce for content (binary, lockable, centralised-friendly). Bridges and tooling integrate the two; the engineering effort is real but pays off.

Cost

Perforce / Helix Core licences are per-user and not cheap. For small teams without binary-heavy workflows, the cost rarely justifies the features. For studios where artists outnumber engineers and the daily grind involves 50 GB scenes, Perforce's pricing is rounding error against productivity.

Choose by workload. Many teams rightly run both.