History on one machine
Revisions are kept locally. Simple and independent, but sharing and coordinated merging are not built into the model.
- Network not required
- Collaboration needs another mechanism
- Examples: RCS and early local tools
The difference is not whether files are shared. It is where the full history lives and which operations need a server.
Revisions are kept locally. Simple and independent, but sharing and coordinated merging are not built into the model.
A central server maintains the authoritative history. Working copies hold files and metadata; committing new revisions normally requires the server.
Each clone has its own repository. Commits can be created locally; peers exchange history through pull and push.
Central workflow, distributed tool: a Git team may still designate one hosted repository as the place for reviewed changes. That is a social convention, not a different storage model.
The files you edit. It is a view of one project state, with local changes layered on top.
A recorded change with identity, metadata, and a link to earlier history. The exact storage differs by system.
A name that helps find a revision. Git branches move with new commits; tags typically identify a chosen point.
| Model | Complete history on each client? | Commit while offline? | Typical trade-off |
|---|---|---|---|
| Local | Only on the local machine | Yes | Easy solo use; collaboration is external. |
| Centralized | No; server holds the authoritative repository | Usually no | Simple central governance; server is part of everyday work. |
| Distributed | Yes, in a full clone | Yes | Flexible work; teams must manage synchronization and policy. |