---
title: 'Centralized and Distributed Models'
source: 'https://academia.sh/en/courses/introduction-to-version-control/centralized-and-distributed-models'
course: 'Introduction to Version Control'
language: en
updated: '2026-08-17T18:10:47+00:00'
license: 'CC BY-SA 4.0'
---

# Centralized and Distributed Models

The design consequences of keeping history on a single server versus in every copy; the reason a version's identity is produced from a content hash rather than an increasing number.

The previous lesson defined history as a directed acyclic graph but did not say where
this graph stands. Is it kept on a single server, or does every participant's machine
hold a complete copy? This question is not an implementation detail: the answer
determines which operations the system can perform without a network connection, how
version identities are produced, and what is lost at the moment of a failure.

## The Centralized Model

In **centralized version control**, history has a single authoritative copy, and it
stands on a server. Participants' machines hold only a **working copy**: the state of
the files at a given version, plus a small record saying which version it was taken
from. History itself is not present locally.

In this scheme, every operation goes to the server:

- Writing a new commit requires connecting to the server.
- Seeing a past version is requested from the server.
- The difference between two versions is computed on the server, or the missing data
  is pulled from the server.

What is gained in return is a simple source of truth. The question "what is the
project's current state" has a single answer, and that answer is on the server.
Access control is also applied at a single point: write permission to a given
directory can be limited by the server.

## The Distributed Model

In **distributed version control**, every copy is complete. When a repository is
taken, not just the latest version but the whole of history — every commit, every
snapshot — is written to the local machine. What the participant holds is not a
working copy but a full **repository**.

The result is a split in the set of operations:

| Operation | Centralized | Distributed |
|---|---|---|
| Writing a commit | Server required | Done locally |
| Listing history | Server required | Done locally |
| Diffing two versions | Server required | Done locally |
| Returning to a past version | Server required | Done locally |
| Taking someone else's work | Server required | Network required |
| Sharing your own work | Server required | Network required |

The network is required only in the last two rows. This split is why every lesson of
this course can be done without a network connection: the repository set up over the
course will stay local and be functional on its own. The **remote** concept is the
subject of the Branching and Collaboration course.

## The Identity Problem

The two models' most instructive difference is in how a version is named.

In the centralized model, the server is the sole authority; it can number versions
with an increasing count. Version 8 comes after version 7, and there is no dispute
over who assigns this number. The number carries both identity and ordering
information: 8 is after 7.

There is no such authority in the distributed model. If two people, unaware of each
other, write a commit on the same predecessor, both would pick the same value as the
"next number." The result is two different commits carrying the same identity, and
history becomes inconsistent. An increasing number requires a central counter.

The solution is to derive identity not from an external counter but from the content
itself. A commit's identity is a hash value computed over all of the commit's
components — its snapshot, its predecessor's identity, its author, its time, its
message. This choice has three consequences:

1. **Producing an identity requires no coordination.** Everyone computes their own
   commit's identity locally; the collision probability reduces to the hash
   function's **collision resistance**.
2. **Identity is content's integrity check.** If a single byte of a commit changes,
   its identity changes too. Corruption in the repository does not stay silent.
3. **Identity carries no ordering information.** One hash value is not "after"
   another hash value. Order is read only from the predecessor links — that is, from
   the graph itself.

The third consequence is exactly what made the previous lesson's discussion of
topological order necessary: ordering history is done not by comparing identities,
but by walking the graph.

Deriving identity from content settles one more point: since the predecessor's
identity is part of the computation, changing a past commit changes the identity of
every commit after it. History is sealed to itself, back from its tip — a sealing
whose consequences appear again in the third topic's "amending a commit" and "reset"
lessons.

## What Is Expected of the Hash Function

Deriving identity from content places a specific load on the hash function used. The
Data Structures course examined hash functions as a dictionary structure's
distribution tool; there, a collision was a performance problem solved by chaining or
open addressing. Here, there is no solution for a collision: if two
different pieces of content produce the same identity, the repository can put one in
place of the other.

For this reason, the expected property is not distribution but **collision
resistance**: it being computationally infeasible to find two different pieces of
content that produce the same identity. Ordinary checksums do not carry this
property; cryptographic hash functions are designed to carry it.

The property is time-dependent: once a method for producing collisions against a
hash function is found, repositories relying on that function need to be migrated to
a stronger one. The repository format carries a version field, and the object
identity's length depends on the format, precisely to make this migration possible. The identities shown in this course consist of forty hexadecimal
characters; in a repository using a different hash function the length differs, but
the model is the same.

## Redundancy and Failure

In the centralized model, the server is a single point of failure. If the server is
unreachable, writes stop; if the server's data is lost and there is no backup,
history is lost. Because working copies hold only the latest version, the past cannot
be brought back.

In the distributed model, every copy is a full backup. Even if a central server is
used — and in practice it usually is — that server is a coordination point, not the
only copy. For history to be lost, every copy would have to be lost.

In return, the distributed model brings two costs:

- **Storage.** Every participant keeps the whole of history. In projects with a long
  lifetime and large files, this cost becomes noticeable; a large binary file that
  entered history stays in every copy even after it is later deleted.
- **Access control.** Since the whole of history is present in every copy, the
  restriction "only certain people should see this directory" cannot be enforced at
  the repository level. Control shifts to the point where sharing happens.

The practical consequence of the second point is that secrets must never enter a
repository. Even if a password is deleted after being committed, it stays in history
and has spread to every copy. The ignore-rules lesson takes up this subject again.

## What the Model Choice Determines

The choice between the two models determines which operations the tool makes cheap.
In the distributed model, writing a commit is cheap because it requires no network;
because it is cheap, it is done often; because it is done often, every commit can be
small and single-purpose. The "atomic commit" habit covered in the next topic is a
direct consequence of this cost structure.

In the same way, since the whole of history is present locally, querying the past is
cheap. Finding which commit changed a given line involves no network latency; this
also turns looking at the past into an ordinary reading habit.

## Summary

- In the centralized model, history is kept on a single server; participants hold
  only a working copy.
- In the distributed model, every copy contains the whole of history; the network is
  needed only for sharing.
- The centralized model can assign version numbers with an increasing count; the
  distributed model has no central counter for this.
- Distributed systems therefore derive identity from content; identity also provides
  an integrity check, but it carries no ordering information.
- The distributed model's costs are storage and the impossibility of enforcing access
  control at the repository level.

## Next Step

The model's vocabulary is complete. The next step is to build this model's concrete
counterpart: turning an empty directory into a repository, seeing what is inside the
resulting `.git` directory, and understanding which configuration layer determines
the author's identity. The next lesson will set up the course's example repository
from scratch.