GitDistributed vs Centralized VCS

Distributed vs Centralized VCS

Git is a distributed version control system. Subversion, CVS, Perforce, and TFS are centralized version control systems. The distinction shapes how each tool feels to use, what it is good at, and what its weak spots are. If you have only ever used Git, the comparison helps you appreciate why it works the way it does.

The central question

Where does the history of the project live?

  • Centralized VCS: History lives on one server. Each developer has only the latest version of files on their machine.

  • Distributed VCS: History lives on every developer’s machine. Each clone is a complete copy of the project — every commit, every branch, all the metadata.

How Centralized VCS works

Centralized model

Text
         ┌────────────────┐
         │  CENTRAL       │   ◀── single source of truth
         │  SERVER         │       holds full history
         │  (full history) │
         └───────┬────────┘
                 │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
     Alice     Bob       Charlie
   (working   (working   (working
    copy)      copy)      copy)

The flow with a centralized VCS:

  • checkout — get the latest snapshot of files from the server.

  • Edit files locally.

  • commit — send your changes back to the server. They immediately become part of the official history that everyone shares.

  • update — pull other people’s commits from the server.

  • Branches live on the server too — usually heavyweight and slow.

How Distributed VCS works

Distributed model

Text
        ┌────────────────────┐
        │  REMOTE (origin)   │  ◀── shared meeting point
        │  full history      │       (often on GitHub)
        └────────┬───────────┘
                 ▲
       fetch/    │   /push
       pull      │
       ┌─────────┼─────────┐
       ▼         ▼         ▼
     Alice     Bob       Charlie
   (FULL      (FULL     (FULL
    history)   history)  history)

The flow with a distributed VCS like Git:

  • clone — copy the entire repository (every commit ever) onto your machine.

  • Edit, add, commit — all happen locally. No network is involved.

  • fetch / pull — download other people’s commits from a remote into your local copy.

  • push — upload your local commits to a remote.

  • Branches live everywhere — they are just pointers, cheap to create and delete.

A subtle point
Git does not *require* a remote. You can use Git for a personal project that lives only on your laptop forever. Remotes are a convention, not a structural requirement.
Side-by-side comparison

Aspect

Centralized (SVN, Perforce)

Distributed (Git, Mercurial)

Where is history stored?

Only on the central server

On every clone

Does daily work need internet?

Yes

No

Speed of commit/log/diff

Network-bound (slow)

Local (fast)

Branch creation cost

Heavy (server copy)

Trivial (a 41-byte file)

Merging culture

Avoided

Routine and encouraged

Risk of total loss

High if server has no backup

Low — every clone is a backup

Permission model

Server-enforced

Convention-enforced

Working offline

Cannot commit

Full functionality

Conflict frequency

High (long-lived branches)

Low (short-lived branches)

Learning curve

Shallow

Steeper (more concepts)

Strengths of centralized VCS

  • Simple mental model. “The server has the truth, I have a working copy.” Familiar to anyone who has used a network file share.

  • Easy access control. The server decides who can read and write. You can lock files so only one person edits at a time (useful for binary assets in game development).

  • Smaller local footprint. You only download the current snapshot, not the full history.

  • Linear history by default. No confusing graph — commits go in a straight line.

Weaknesses of centralized VCS

  • Single point of failure. Server down or destroyed = nobody can commit; with no backup, history is gone.

  • Network round-trips for everything. Slow over poor connections.

  • Heavy branching. Branches are server-side copies, which discourages experimental work.

  • Painful merging. Long-lived branches → big merges → conflicts. Teams avoid branches → harder to do feature work in parallel.

  • No offline workflow. You cannot commit on a plane.

Strengths of distributed VCS

  • Speed. Almost all operations are local. git log of a 20-year-old project is instant.

  • Resilience. Every clone is a full backup. If GitHub vanishes overnight, you push your local repo to a different host and you are back online.

  • Cheap branching. Branches are free, so teams create them for every change. This enables the modern feature-branch / pull-request workflow.

  • Better merging. The DVCS data model (every commit knows its parents) was designed for merging from the start. Conflicts still happen, but the algorithms are stronger.

  • Offline work. Commit, branch, search history, diff — all without internet.

  • Many workflows possible. You can have a strict central host, or a fork-based open-source workflow, or peer-to-peer collaboration.

Weaknesses of distributed VCS

  • Steeper learning curve. More concepts: remotes, fetching vs pulling, rebasing, merging strategies, the staging area.

  • Large repos can be slow to clone. The whole history downloads on first clone. (Mitigated by --depth=1 shallow clones or partial clones.)

  • Harder to enforce strict access control on individual files. Permissions are usually at the repo level. Tools like Gerrit and branch protection rules fill the gap.

  • Binary files are painful. Git stores full snapshots; binary files duplicate badly. Use Git LFS or another approach.

  • No file locking out of the box. Two people can edit the same file at once and have to merge later. (LFS adds locking for binary assets.)

When does centralized still make sense?

  • Game studios with huge binary assets and heavy file-locking needs — Perforce is still dominant here.

  • Heavily regulated industries (finance, defense) where every read needs to be audited centrally.

  • Legacy enterprise codebases that have been on SVN for decades and have working tooling around it.

  • Very small teams who genuinely never need branches or offline work — though even then, Git costs them nothing extra.

How Git emulates a “central” workflow

In practice, almost every Git team picks one remote (usually on GitHub, GitLab, or Bitbucket) and treats it as the canonical source. So culturally Git often feels like a centralized workflow — but underneath, every developer still has the full history locally. The “central” remote is convention, not requirement.

The convention most teams use

Bash
# 'origin' is just a name for the team's shared remote
git clone git@github.com:team/project.git
# → you now have a full local copy

# Daily work happens locally
git switch -c my-feature
# ... edit, add, commit ...

# Share your work
git push origin my-feature
# Open a Pull Request on GitHub
# Teammates review, you merge into main
# Everyone pulls main to stay current
Warning
Even with a shared remote, treat your local clone as authoritative for *your* work. Always push your branch before reformatting your laptop, and never rely solely on the remote as your only copy of in-progress work.
Tip
The phrase “Git is distributed” does not mean you have to use it in a fancy peer-to-peer way. It just means the *tool* supports that. Most teams use a “hub-and-spoke” pattern with one shared host — and that’s perfectly fine.