linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
Intro
Lessons
Footer
linuxlab-TutorialsPricingAboutPrivacy & cookies
Copyright © 2026 LinuxLab. All rights reserved.
linuxlab.io
Tutorials▾
  • Linux & networking
    File system, processes, TCP/IP, BGP and OSPF
    →
  • Terraform & IaC
    HCL, state, plan/apply on a LocalStack sandbox
    →
  • Git & GitHub
    Object model, plumbing, branching, GitHub Actions
    →
All tutorials →
PricingAboutSign inCreate account
/
  • Introduction
  • Chapters
  • How it works
  • Lessons
  • Knowledge base
  • Interview prep
home/git/kb/Git basics/distributed-vcs

kb/basics ── Git basics ── beginner

Distributed version control system

A VCS where every developer holds a full copy of the history, not just a snapshot. Git, Mercurial, Bazaar. The key difference from centralized systems (SVN, CVS): no single point of failure, and no network required for most operations.

view as markdownaka: dvcs, distributed-version-control

A distributed version control system (Distributed VCS, DVCS) is a type of VCS where every clone of the repository contains the full history of the project. Not "a snapshot of the current version," as centralized systems provide (see vcs), but literally every commit from the first to the last.

The main examples are Git, Mercurial, and Bazaar. Less common are Darcs, Pijul, and Fossil.

What changes compared to centralized

A server is technically unnecessary

Two developers can synchronize directly: "pull my changes." In practice a server still appears, because it is convenient as a meeting point (GitHub, GitLab) and as a backup. But it is not the authority. It is one equal clone among others.

Working without a network

Commits, branches, history, search: all local, all instant. The network is needed only to synchronize with others via push and pull.

Speed

A local operation is a disk read. An SVN client has to contact the server and wait for a response. A Git client does not.

Cheap branches

Creating a branch writes 40 characters to a file (see branch). In SVN a branch is a directory copy on the server. That changes how you work: in Git you create a branch for every task; in SVN developers were afraid to branch at all.

Reliability

History is duplicated on every developer's machine. Losing it requires destroying every clone simultaneously. Compare that to a centralized setup: one server goes down without a backup, and everything is gone.

The cost

  • Disk space. Every clone contains the full history. For repositories measured in gigabytes, that is noticeable. Mitigations: git clone --depth=1 (shallow), git lfs for binary files.
  • A slightly steeper mental model. You need to understand that your local commit and the commit on the server are different objects until you run push.

History

BitKeeper was the first widely known DVCS, released in 1998. Linus Torvalds used it for the Linux kernel from 2002 to 2005. After the free license was revoked in 2005, Linus wrote Git in 10 days.

In parallel, Mercurial and Bazaar appeared in 2005: both distributed, both built on similar ideas. Technically they were no worse than Git. Git won for two reasons: the Linux kernel moved to it immediately, and GitHub launched in 2008.

Comparison

Centralized (SVN)Distributed (Git)
History on clientcurrent version onlyfull
Network for commitsrequirednot needed
Branchesexpensive (directory copy)free (40 bytes)
Single point of failureservernone
Client storage sizesmallproportional to history

§ см. также

  • vcsVersion control systemA tool that stores the history of file changes, lets you return to past versions, and lets multiple people collaborate on the same project. Three generations: local, centralized, distributed.
  • snapshot-vs-deltaSnapshots vs. deltasThe core conceptual difference between Git and SVN/CVS/Perforce. Older VCS store each version as a diff from the previous one. Git stores each version as a complete snapshot of the project, with deduplication of identical files via SHA.
  • branchBranchA branch in Git is a file inside `.git/refs/heads/` that holds the SHA of one commit. Creating, switching, and deleting branches are trivial operations because a branch contains exactly 41 bytes of data.
  • working-treeWorking treeThe files and directories of your project on disk: the ones you open in your editor. One of Git's three zones, alongside the index ([[add]]) and the repository ([[commit]]).
Footer
linuxlab-
Copyright © 2026 LinuxLab. All rights reserved.
Tutorials
Pricing
About
Privacy & cookies