Chapter 1.1☕ 12 min read

What is Git & How It Works

Folder_FINAL_v2 se thak gaye? Git seekho — ek baar, sahi tarike se.

01What is a VCS & Why Distributed?

Before Git, developers had one system for tracking changes: folder copies. project_v1, project_v2, project_FINAL, project_FINAL_v2 — we have all been there. This is madness, not version control.

A Version Control System (VCS) is software that tracks changes to files over time so you can recall specific versions later. It is the difference between guessing which file is latest and knowing exactly what changed, when, and by whom.

Three generations of VCS evolved:

Local VCS (like RCS) — diffs stored locally on your machine. Simple, but no collaboration.
Centralized VCS (like SVN) — single central server, everyone pulls and pushes to it. Easy to understand, but one massive flaw.
Distributed VCS (like Git) — every clone is a full repository with complete history. No single point of failure.

The fatal flaw of centralized VCS: single point of failure. Server down = no one can commit, no history access, no collaboration. Your entire team is blocked.

Distributed = every developer has the FULL repository with FULL history. Work offline. No single point of failure. Internet down? Keep committing. Server crashed? You have a complete backup. Git is a DVCS — Distributed Version Control System.

# Before Git — folder madness
project_v1/
project_v2/
project_FINAL/
project_FINAL_really/
project_FINAL_v2_sai_edits/
project_submitted/
project_submitted_fixed/ ← which one is production??

Centralized VCS (SVN) has a single central server. If the server crashes, NOBODY can commit or access history. Git is distributed — every clone IS a full backup. You can work offline, then sync later. This is why Google, Microsoft, Linux kernel — all use Git.

02Snapshots vs Diffs — The Big Difference

The most fundamental misunderstanding about Git: beginners think Git stores diffs (changes between versions). Git stores snapshots.

A snapshot = complete picture of ALL tracked files at that moment. Like a photograph of your entire project. Every commit captures the full state.

If a file did not change, Git does not store it again — it stores a reference (pointer) to the previous identical file. Efficient!

SVN/CVS store diffs: to reconstruct version 10, they replay diffs from version 1 to 10. Slow for old history.
Git stores snapshots: to reconstruct any version, Git goes directly to that snapshot. Fast, regardless of history depth.

Nearly all Git operations are LOCAL — git log, git diff, git blame work without internet because you have the full history on your machine.

# SVN/CVS approach — store diffs
Version 1: (base file)
Version 2: + line 5 added
Version 3: - line 3 removed, + line 8 changed
Version 4: + function added at line 20
# To see version 4: replay ALL diffs from v1. Gets slower with history.

# Git approach — store snapshots
Commit A: [snapshot of all files]
Commit B: [new snapshot — unchanged files stored as reference]
Commit C: [new snapshot — only changed files stored fresh]
# To see any commit: go directly to that snapshot. Always instant.

💡 Pro Tip: Nearly all Git operations are LOCAL. git log, git diff, git status, git blame — all run on your machine using local data. No network needed. This is why Git feels so fast compared to SVN where every operation hits the network.

03The .git/ Directory — The Heart of the Repo

When you run git init, Git creates one hidden folder: .git/

.git/ IS the entire repository. The working directory (your project files) is just a checkout of one particular snapshot.

If you delete .git/ → your folder becomes a normal folder. No history, no Git. That is it. Game over.

If you copy .git/ somewhere else → you have a full copy of the repository with complete history.

Key contents of .git/:

HEAD — text file: which branch you are currently on
objects/ — all commits, file contents, directory structures stored as SHA-1 hashes
refs/ — branches and tags (just pointers to commit hashes)
index — the staging area (binary file)
config — repository-specific configuration
hooks/ — automation scripts

Git uses SHA-1 to hash everything — 40-character hex string. Same content = same hash, always.

mkdir demo && cd demo
git init
# Initialized empty Git repository in /demo/.git/

ls -la
# .git/   ← this is the ENTIRE repository

ls .git/
# HEAD    config    hooks/    objects/    refs/

cat .git/HEAD
# ref: refs/heads/main

# Delete .git = delete the repository
rm -rf .git
git status
# fatal: not a git repository

04SHA-1 Hashing — How Git Identifies Everything

Git identifies EVERYTHING by SHA-1 hash — 40 hex characters like a94a8fe5ccb19ba61c4c0873d391e987982fbbd3

SHA-1 is computed from the content itself — same content always produces the same hash. This is called content-addressable storage.

If two files have identical content, Git stores ONE blob with one hash. Deduplication is automatic.

A commit hash is computed from: tree hash + parent hash + author + committer + message + timestamp. Change anything = new hash.

This is why amending a commit changes its hash. History is immutable by design.

This is why you can verify integrity: git fsck checks all objects. Any bit flip or corruption = hash mismatch = detected immediately.

Short hashes: Git lets you use first 7 characters (e.g., a94a8fe) as long as they are unique in the repo.

# Git hashes the content to get the object ID
echo "hello" | git hash-object --stdin
# ce013625030ba8dba906f756967f9e9ca394464a

# Same content ALWAYS = same hash
echo "hello" | git hash-object --stdin
# ce013625030ba8dba906f756967f9e9ca394464a

# Different content = different hash
echo "Hello" | git hash-object --stdin
# 1d229271928d3f9e2bb0375bd6ce5db6c6d348d9
# (capital H → completely different 40 chars)

# Two files with SAME content → ONE blob stored
echo "hello" > file1.txt && echo "hello" > file2.txt
git add file1.txt file2.txt
git ls-files -s
# 100644 ce013625... file1.txt
# 100644 ce013625... file2.txt
# SAME hash! One blob, two references. Zero duplication.

The SHA-1 hash of a commit includes its parent hash. This creates an unbreakable chain — you cannot change commit #3 without changing commit #4, #5, #6... all the way to the latest. This is why Git history is tamper-evident. It is the same principle as blockchain — hash chains make history immutable.

05History — Git in 10 Days by Linus Torvalds

2005: The Linux kernel was using BitKeeper (a proprietary DVCS). BitKeeper revoked the free license for the Linux project.

Linus Torvalds was furious. He wrote Git in 10 days. Not a typo. Ten days.

His requirements were crystal clear: speed (Linux has 30,000+ files), distributed, simple design, strong branching, and full integrity verification.

Git became the dominant VCS within 5 years. GitHub launched in 2008 and accelerated adoption massively by making collaboration easy.

Today: 94% of developers use Git (Stack Overflow 2022 survey). GitHub has 100M+ developers and 330M+ repositories.

The name: Linus called it "git" (British slang for stupid/unpleasant person) — "I name all my projects after myself. First Linux, now Git."

Key competitors Git beat: SVN (centralized, slow), Mercurial (similar to Git but lost the ecosystem war), Perforce (enterprise, expensive).

💡 Git's Design Philosophy: Do one thing — track content — and do it with maximum efficiency. Git does not care about your build system, deployment, or workflow. It just tracks what changed, when, by whom, and why. Everything else (GitHub, GitLab, CI/CD) is built ON TOP of Git. Git itself is just a content-addressable filesystem with a version control layer.

Lo kar liya — Key Points:

✅ Git is a Distributed Version Control System — every clone has the FULL history, not just the latest files
✅ Git stores SNAPSHOTS, not diffs — each commit is a complete picture of all tracked files at that moment
✅ Unchanged files are stored as references (pointers), not copies — automatic deduplication via SHA-1 hashing
✅ The .git/ directory IS the repository — working directory is just a checked-out snapshot
✅ SHA-1 hashing makes history tamper-evident — changing any commit changes all subsequent commit hashes
✅ Nearly all Git operations are LOCAL — git log, git diff, git blame need no network connection
✅ Linus Torvalds wrote Git in 10 days in 2005 — built for speed, distribution, and integrity

Previous—📋 All Chapters Next Chapter1.2 — Setup & First Commit →