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/vcs

kb/basics ── Git basics ── beginner

Version control system

A 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.

view as markdownaka: version-control, version-control-system

A version control system (VCS) is a program that tracks changes to files and stores their history. Any program that does this automatically qualifies as a VCS: from simple utilities like RCS to distributed systems like Git.

Why you need one

Without a VCS you store file versions by hand:

report.docx
report_v2_FINAL.docx
report_v3_URGENT.docx

That works for one file and one person. It stops working when a project has hundreds of files and several developers.

VCS solves three problems:

  1. Names stay meaningful. Versions are labeled by date, author, and message, not by filename suffixes.
  2. Collaboration. Multiple people edit the same files, and the system helps resolve conflicts.
  3. Storage efficiency. Instead of a full copy of every version, the system stores a diff (or a deduplicated snapshot, see snapshot-vs-delta).

Three generations

Local

History is stored in a service directory alongside the files. RCS (1982), SCCS (1972). The advantage is simplicity. The disadvantage: all history sits on one machine, so a disk failure means history gone.

Centralized

History lives on a central server. Developers hold only the current snapshot. CVS (1986), Subversion (2000), Perforce. The advantage is collaboration. The disadvantage: dependence on the server and the network.

Distributed

Every developer holds a full copy of the history. See distributed-vcs. Git (2005), Mercurial (2005), Bazaar (2005). The advantages are offline work, cheap branches, and reliability. The disadvantage is a slightly steeper mental model.

Which to choose

In 2026 the choice for most new projects comes down to Git: it has the largest ecosystem of hosting services (GitHub, GitLab, Bitbucket) and tooling. Other systems occupy niches:

  • Git is the de facto default in open source and most companies.
  • Mercurial was historically used by Mozilla and Facebook; it is less common today. Technically it is no worse than Git.
  • Perforce is used by large game studios and the film industry, where large binary files are common.
  • SVN persists in old corporate projects that have not migrated "because it works."

This book is about Git. Equivalents for concepts from other VCS are in appendix B.

§ см. также

  • distributed-vcsDistributed version control systemA 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.
  • 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.
  • 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