> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Distributed Version Control
> Explains differences between centralized and distributed version control, highlights Git’s distributed advantages for offline work, redundancy, and team collaboration with remotes like GitHub
This page compares distributed and centralized version control systems and explains why Git’s distributed design changed how teams collaborate.
Legacy centralized systems such as [CVS](https://en.wikipedia.org/wiki/Concurrent_Versions_System), [Subversion](https://subversion.apache.org/), and [Perforce](https://www.perforce.com/) rely on a single central server that stores the entire project history. That central server is a single point of failure: if it goes down, developers can be blocked and the project history can become difficult to recover.
Git is a distributed version control system: every developer’s clone contains a full, independent copy of the repository — including the entire commit history. That architecture provides several practical advantages for both solo and team workflows:
* Work offline: you can commit locally without network access, keeping incremental history on your machine.
* Reduced coupling to remotes: network connectivity is required only when exchanging changes with a remote (for example, `push`, `fetch`, or `pull`).
* Redundancy and recovery: any clone with the required history can act as a backup of the project, reducing the risk of total data loss (note: shallow clones that omit older commits are an exception).
Common Git operations you’ll use when collaborating with remotes:
```bash theme={null}
# Record local work
git add .
git commit -m "Describe changes"
# Send local commits to a remote
git push origin main
# Retrieve remote changes (two common ways)
git fetch origin
git merge origin/main
# or (shortcut)
git pull origin main
```
Distributed does not mean “no server.” Most teams use remote hosting (for example, GitHub, GitLab, or a self-hosted Git server) to simplify collaboration, code review, CI/CD, and backups while still benefiting from Git’s distributed model.
In practical team environments, a hybrid approach is the norm: developers use full local history for offline work and fast local operations, and they rely on one or more remote hosts to coordinate sharing, run CI/CD, and enforce access control.
Beware of shallow clones (e.g., `git clone --depth `). They omit older history and can prevent full repository recovery if a remote is lost. Use shallow clones only when you understand the trade-offs.
Summary comparison
| Model | Server role | Failure impact | Typical examples / hosts |
| ----------- | ---------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------- |
| Centralized | Central server holds the authoritative history | Single point of failure; clients need server for many operations | `CVS`, `Subversion`, `Perforce` |
| Distributed | Every clone contains full history | Any up-to-date clone can restore the repository | `Git`, hosted on GitHub, GitLab, or self-hosted servers |
Links and references
* [Git — official site](https://git-scm.com/)
* [GitHub](https://github.com/)
* [GitLab](https://gitlab.com/)
* [Subversion — Apache](https://subversion.apache.org/)
* [CVS — Wikipedia](https://en.wikipedia.org/wiki/Concurrent_Versions_System)
In short: Git’s distributed architecture removes the single point of failure inherent in centralized systems, enables robust offline workflows, and gives teams flexible options for sharing and backing up history — while remote hosts provide the coordination and services teams typically depend on.