Module 01 — What Version Control Really Is

Goal: Understand the problem Git solves and the core ideas (snapshots, hashes, distributed) before you touch a single command.

1.1 The problem, in everyday terms

Imagine you’re writing an important document. You save it as report.docx. Then you make big changes, but you’re nervous, so you “Save As” report_v2.docx. Then report_final.docx. Then report_final_REALLY.docx. Then report_final_v2_johns_edits.docx.

This is version control done by hand, and it’s terrible:

You can’t easily see what changed between two versions.
If two people edit at once, merging their work is a nightmare of copy-paste.
You can’t safely experiment, because undoing means remembering which file was “good.”
Old versions pile up and you lose track of which is which.

Version control software solves all of this. It is a tool that records the history of your files over time, lets many people work on them at once, and lets you move backward and forward through that history safely. Git is by far the most popular version control system in the world.

1.2 What Git actually does (the one-sentence version)

Git takes a complete snapshot of your project every time you ask it to, gives that snapshot a unique fingerprint, and stores every snapshot forever so you can always go back, compare, or branch off.

That’s it. Everything else — branches, merges, GitHub, pull requests — is built on top of that single idea.

1.3 Snapshots, not differences

Here’s a concept that trips up beginners. Many older version-control tools stored your history as a list of changes (deltas): “in version 2, line 5 changed from X to Y.” Git is different. Conceptually, Git stores snapshots.

Every time you commit, Git essentially photographs the entire state of every tracked file at that moment. If a file didn’t change since the last snapshot, Git is smart and just points to the previous copy instead of storing it again (so it’s efficient), but the mental model you should hold is:

A Git history is a series of complete snapshots over time, like frames in a film reel.

This is why Git can switch you between versions instantly and reliably — it’s not replaying a list of edits, it’s just showing you a frame.

1.4 The hash: every snapshot has a fingerprint

When Git stores something, it runs the content through a mathematical function that produces a 40-character fingerprint that looks like this:

e83c5163316f89bfbde7d9ab23ca2e25604af290

This is called a hash (specifically a SHA-1 hash; newer Git also supports SHA-256). The key properties:

The same content always produces the same hash.
Different content (even one character) produces a wildly different hash.
The hash is effectively unique, so Git uses it as the “address” of each snapshot.

You’ll see these hashes everywhere. When you make a commit, Git replies with one. You usually only need the first 7 characters (e83c516) to refer to it. We’ll see in Module 04 that hashes are literally how Git names the files it stores on disk.

1.5 “Distributed” — why every clone is a full backup

You’ll hear Git described as a Distributed Version Control System (DVCS). Here’s what that means in plain terms.

With older, centralized systems, there was one server that held the entire history. Your computer only had the latest version checked out. If the server died, history could be lost; if you were offline, you couldn’t commit.

With Git, every copy of a repository contains the complete history. When you “clone” a project from GitHub, you download every snapshot ever made, all the branches, everything. Consequences:

You can commit, branch, view history, and compare versions completely offline.
Every developer’s laptop is a full backup of the whole project.
GitHub is not “the real repository” — it’s just one copy that everyone agrees to treat as the shared meeting point. Git itself has no concept of a “central” server; that’s a convention, not a requirement.

This distinction matters later: when we talk about push and pull (Module 06), you’ll understand they’re just syncing two complete copies of the same database.

1.6 Repository, commit, branch — the three words to know

Three terms appear constantly. Quick definitions (each gets its own deep dive later):

Repository (repo): A project tracked by Git. Physically, it’s your project folder plus a hidden .git subfolder that holds the entire history. The .git folder is the repository’s database.
Commit: One saved snapshot, with a hash, an author, a date, and a message describing what changed. Commits are the units of history.
Branch: A movable label that points to a commit, letting you develop a feature in isolation without disturbing the main line of work. Despite sounding heavy, a branch is almost weightless — we’ll see in Module 04 that it’s literally a tiny file containing one hash.

1.7 How commits link together (the chain)

Each commit (except the very first) records the hash of the commit that came before it — its parent. So commits form a chain:

A ◄── B ◄── C ◄── D     (D is the newest; each arrow means "my parent is...")

This chain is the project’s history. A branch is just a pointer to one commit in this chain (say, D). Because each commit knows its parent, Git can walk backward from any commit to reconstruct the entire history that led to it. When two lines of development split and rejoin, a commit can have two parents — that’s a merge commit (Module 05).

1.8 Git vs. GitHub — clearing up the biggest confusion

Beginners constantly mix these up:

Git is the free, open-source software that runs on your computer and does all the version-control work. It was created by Linus Torvalds (the creator of Linux) in 2005.
GitHub is a company and website (owned by Microsoft) that hosts Git repositories online and adds collaboration features — pull requests, issues, code review, automation, and of course GitHub Copilot.

You can use Git with no GitHub at all. You can also use other hosts (GitLab, Bitbucket). GitHub just happens to be the most popular, and it’s where Copilot lives. We cover GitHub starting in Module 06.

Try it yourself

You don’t need Git installed yet to do this thought exercise:

Look at any folder on your computer where you’ve made _v2, _final style copies. That’s manual version control — note how hard it is to tell what changed.
Re-read section 1.2 and say the one-sentence model out loud. If you remember only one thing from this module, make it that sentence.

Key takeaways

Git records the history of files so you can go back, compare, and collaborate safely.
Mentally, Git stores snapshots, each identified by a unique hash.
Git is distributed: every clone is a full copy of the entire history, so you can work offline.
A commit is a snapshot; a branch is a pointer to a commit; a repository is your project plus its .git history.
Git is the tool; GitHub is a website that hosts Git repos and adds collaboration and Copilot.

Next: Module 02 — Installing & Configuring Git