Centralized vs Distributed

Version control systems can be divided into two main models: Centralized Version Control Systems and Distributed Version Control Systems.

The main difference between them is where the repository history is stored and how developers access it.

Centralized Version Control System

In a Centralized Version Control System (CVCS), one central server stores the main repository and its version history.

Developers connect to that server and check out a working copy of the project onto their machines. Their local machines usually contain the files they are currently working on, while the central server remains the primary source of the project’s history.

SVN is a common example of a centralized version control system.

How It Works

A central server stores the repository and its history.
Each developer checks out a working copy.
Developers edit the project files on their machines.
They connect to the central server to commit or retrieve changes.
The central repository acts as the team’s source of truth.

Advantages

The project is managed from one central location.
Team members work against one shared repository.
Access control and administration can be simpler.
It is easy to understand which repository is the official one.

Limitations

Many operations require a network connection.
If the central server becomes unavailable, collaboration may stop.
Developers may be unable to commit or retrieve changes during the outage.
If the server is permanently lost without a valid backup, the project history may also be lost.
The central server represents a single point of failure.

Distributed Version Control System

In a Distributed Version Control System (DVCS), every developer receives a complete clone of the repository.

A clone contains more than the current project files. It also contains the repository’s history, commits, branches, and other Git data.

Git is a distributed version control system.

How It Works

Each developer clones the complete repository.
Every clone contains the full project history.
Developers can edit files, create commits, inspect history, and create branches locally.
A network connection is only required when developers need to synchronize changes with another repository.
Synchronization is commonly performed using operations such as push, pull, and fetch.

Advantages

Every developer has a complete copy of the repository and its history.
Most Git operations can be performed offline.
Developers can create commits and branches without contacting a central server.
Local clones provide additional protection against losing the project history.
Work can continue locally when a hosting service is temporarily unavailable.
Teams can use different collaboration workflows.

Important Clarification

Having a distributed repository does not mean that every developer works separately forever.

Teams commonly use a shared remote repository hosted on a service such as GitHub, GitLab, or Bitbucket. This remote repository provides a convenient central meeting point where team members exchange and review their changes.

However, Git remains distributed because every developer still has a complete local repository.

What Happens If GitHub Is Down?

If GitHub becomes temporarily unavailable, developers can still:

Edit project files.
View the local repository history.
Create local commits.
Create and switch between branches.
Compare and restore local versions.

However, they cannot synchronize with the unavailable GitHub remote. Operations such as push, pull, and fetch will not work until the service becomes available again.

This demonstrates how Git combines the resilience of distributed version control with the convenience of a shared collaboration server.

Centralized vs Distributed: Quick Comparison

Centralized VCS

Repository history: Stored mainly on one central server.
Local copy: Usually a working copy.
Offline commits: Usually unavailable.
Offline branches and history: Limited or unavailable.
Network usage: Required for many operations.
Server outage: Collaboration and many operations stop.
Single point of failure: Central server can be one.
Examples: SVN, CVS.

Distributed VCS

Repository history: A complete history exists in every clone.
Local copy: A complete repository clone.
Offline commits: Available.
Offline branches and history: Available.
Network usage: Mainly required for synchronization.
Server outage: Local work continues, but synchronization stops.
Single point of failure: Reduced because complete clones exist.
Examples: Git, Mercurial.

Key Takeaway

A centralized system keeps the main repository and its history on one server.

A distributed system gives every developer a complete copy of the repository and its history.

Git is distributed, while services such as GitHub allow teams to use a shared remote repository as a central collaboration point. This gives developers the benefits of both approaches: complete local repositories and an organized place to share their work.