Origins & Philosophy · lesson 2 of 18

Distributed vs Centralized

Why Git Won

Why it matters

Understanding the difference between centralized (SVN/CVS) and distributed (Git) version control explains why Git commands work the way they do.

Key concepts

Centralized VCS — Single server holds all history (SVN, CVS, Perforce)
Distributed VCS — Every clone has full history (Git, Mercurial)
Clone — Complete copy of repository including all history
Local Operations — Commands that don’t need network (commit, branch, log)

The idea

The Library Analogy

Centralized VCS (SVN/CVS): Imagine a single library with one copy of every book. To read a book, you must go to the library. To write notes in a book, you must check it out (lock), write, and return it (unlock). If the library burns down, everything is lost.

Distributed VCS (Git): Everyone has a complete copy of the library. You can read, annotate, and reorganize your copy anytime, even offline. When you want to share, you sync with others. If any library burns down, dozens of complete copies exist elsewhere.

The Key Differences

Centralized (SVN)	Distributed (Git)
Need network to commit	Commit offline, sync later
Single point of failure	Everyone has full history
Lock-based workflow	Branch-based workflow
Slow branching (copies files)	Instant branching (pointer)
Revision numbers (1, 2, 3…)	SHA-1 hashes

Why Distributed Won

Offline work: Commit on planes, trains, or anywhere without WiFi
Speed: All operations are local except push/pull
Backup: Every clone is a full backup
Experimentation: Cheap branches encourage trying things
Collaboration: Fork, experiment, merge—without asking permission

Walkthrough

Centralized (SVN) Workflow

flowchart TD
    server["Server (trunk): single point of failure"]
    devA["Dev A checkout"]
    devB["Dev B checkout"]
    devC["Dev C checkout"]
    server --> devA
    server --> devB
    server --> devC

Every commit goes directly to the server. No local history.

Distributed (Git) Workflow

flowchart TD
    remote["GitHub remote: optional central hub"]
    cloneA["Clone A: full history"]
    cloneB["Clone B: full history"]
    cloneC["Clone C: full history"]
    remote <-->|push / pull| cloneA
    remote <-->|push / pull| cloneB
    remote <-->|push / pull| cloneC
    cloneA <-->|peer sync| cloneB
    cloneB <-->|peer sync| cloneC

Every clone has complete history. Can sync peer-to-peer.

Speed Comparison

Centralized Subversion, distributed Mercurial, and Git — three answers to the same problem.

Operation	SVN	Git
Commit	Network round-trip	Instant (local)
View history	Network round-trip	Instant (local)
Create branch	Minutes (copies files)	Instant (41 bytes)
Switch branch	Network round-trip	Instant (local)

Key takeaways

In Git, every clone is a full backup
Commit, branch, and log work offline
GitHub is a hub, not a requirement
Distributed = resilient + fast + flexible

Going deeper

SVN is still used: Some organizations still use SVN for large binary assets or strict access control. Git-LFS and Perforce fill this niche for games/media.

Mercurial: Mercurial (hg) was created the same week as Git, also in response to BitKeeper. It’s similarly distributed but more user-friendly. Facebook used Mercurial internally. Git won market share due to GitHub’s network effects.

Common mistakes

Thinking GitHub IS Git: GitHub is a hosting service built on Git. You can use Git without GitHub (GitLab, Bitbucket, self-hosted, or no remote at all).

Treating Git like SVN: Don’t commit directly to main. Don’t avoid branching. Embrace the distributed workflow.