Why Git Matters: A Deep Dive into Distributed Version Control

What is Git?

Git is an open‑source distributed version‑control system that can efficiently handle projects ranging from tiny scripts to massive codebases. It was created by Linus Torvalds to help manage Linux kernel development.

What is version control?

Version control refers to the management of changes to source code, configuration files, and documentation, allowing teams to track modifications, revert to previous states, and coordinate collaborative work.

Version‑control example

A development team of four builds an internal management system with 20 features. After each developer finishes their five features, the manager integrates them into an "initial version". Subsequent bug fixes, redesigns, and new feature additions produce second, third, and later versions, illustrating how version control records each iteration.

Version‑control systems

Local version control

Early systems like RCS stored patches (differences) on disk; applying all patches reconstructs any version. Local VCS often rely on copying entire project directories, which is simple but error‑prone.

Centralized version control

Centralized VCS (CVCS) such as CVS, Subversion, and Perforce use a single server to store all revisions. Clients check out the latest files or submit updates, providing a clear authority but requiring network access and a single point of failure.

Distributed version control

Distributed VCS (DVCS) like Git, Mercurial, Bazaar, and Darcs clone the entire repository to each client. This eliminates the need for constant network connectivity and allows any clone to serve as a backup if the central server fails.

Git features

Speed, simple design, strong support for non‑linear development (thousands of parallel branches), full distribution, and the ability to manage very large projects such as the Linux kernel.

Storage models

Delta storage

Delta storage records only the differences (deltas) between file versions. Only modified files generate snapshots; unchanged files are omitted.

DAG storage

Git uses a Directed Acyclic Graph (DAG) where each commit creates a snapshot of the entire project. Unchanged files are linked to previous snapshots, making storage efficient.

How Git stores data

Git configuration files

After installation, Git creates a hidden .git directory containing configuration files and the object database.

Object database

Objects are stored by hash (SHA‑1) derived from file content and metadata. Files are compressed with zlib and placed in subdirectories named after the first two characters of the hash.

Four Git object types

blob : stores file contents.

tree : stores directory hierarchy.

commit : records a snapshot of the repository (points to a tree and parent commits).

tag : provides a human‑readable name for a commit.

Git workflow

Three states

Committed : data safely stored in the repository.

Modified : changes made but not yet staged.

Staged : changes marked to be included in the next commit.

Three areas

Repository : the hidden .git directory containing metadata and objects.

Working directory : the checked‑out files you edit.

Staging area (index): a file that records which changes will be committed.

Typical workflow

Edit files in the working directory.

Stage the changes (add them to the index).

Commit the staged snapshot to the repository.

Each commit creates a new snapshot; the repository can be used to revert, branch, or merge changes.