Centralized and Distributed Models

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.