The Distributed Model

Updated

October 30, 2026

The Distributed Model

After this page you can explain why every clone is a repository, and what that implies for a hosting server.

Every clone is a full copy

When you git clone, you get:

  • every commit reachable from the branches and tags you fetched
  • a working tree checked out at one branch (usually main)
  • a remote named origin pointing at the URL you cloned

There is no “thin client.” git log, git diff, git commit, git branch, and git merge talk to .git/ on your disk. The network is for fetch (download objects and update remote-tracking names) and push (upload objects and ask the other side to move a name).

your laptop                         a forge
┌─────────────────┐                ┌─────────────────┐
│ .git/objects    │   fetch/push   │ .git/objects    │
│ refs/heads/main │ ←────────────→ │ refs/heads/main │
│ refs/remotes/   │                │ (plus issues,   │
│   origin/main   │                │  CI, packages)  │
└─────────────────┘                └─────────────────┘

Both sides are Git repositories. The forge adds a website, accounts, and extra services. Git itself does not need them.

Implications

Offline work is real. You can commit on a plane. Push when you have a network.

Several remotes are normal. origin is a convention, not a law. You can push the same desk-api history to a laptop USB clone, a Forgejo server, and GitHub. Chapter 22 uses that as an independence move.

The server does not own history uniquely. If the forge vanishes, every up-to-date clone still has the Git objects. What you lose are issues, pull-request comments, CI logs, and packages — the forge’s extras. That split is the rest of this book.

Rewriting shared history is a social operation. git commit --amend and rebase change hashes. On your laptop before anyone fetched, that is fine. After others based work on those hashes, you are asking them to reset. Chapter 9 is the skill; this page is the reason it matters.

Fetch is not pull. git fetch updates origin/main on disk. git pull is fetch plus a merge or rebase into your current branch. Chapter 11 separates them. Prefer fetch until pull’s extra step is a choice you can name.

What a hosting platform must speak

A Git server has to:

  1. Store objects and refs.
  2. Speak the Git protocol over SSH and/or HTTP (smart protocol: the client and server negotiate which objects to send).
  3. Decide who may move which refs (authorization).
  4. Run hooks on receive (the server-side programs that can reject a push).

Everything else — pull requests, CI, registries, SAML — is forge software on top of that. Chapter 23 draws the boxes. Chapter 3 stays on your laptop: git init, add, commit.