Why version control?
A version control system records a project's full history — what changed, when, by whom, and why — so you can roll back to any earlier state. Copying folders by hand loses authorship, parallel work, and recovery; version control is what fixes all three.
You finish a feature and name the folder project-final. Then you fix a bug: project-final2. The client wants the old version back, but you already overwrote it. A teammate emails you their copy and now there are two project-final2 folders that disagree, and nobody can say which line of code is newer or who wrote it. Every developer has lived this. The tool that ends it is version control — and the industry standard is git.
By the end of this lesson you will be able to say what a version control system records, and why the “copy the folder” approach fails the moment more than one person, or more than one day, is involved.
After this lesson you can explain what a version control system (VCS) is, name the four things it records about every change — what, when, who, why — and describe three concrete problems it solves that manual folder-copying cannot.
A version control system records the history of a project, not just its current state. When you copy a folder, you keep one snapshot and lose everything before it. A VCS instead keeps every state the project has ever been in, as a chain of recorded changes. At any moment you can ask: what did this file look like last Tuesday? Who changed this line? What was the project like at the moment we shipped version 1.0? The current files on disk are just the latest point in a long, navigable timeline.
Each recorded change is called a commit, and it stores four things. A commit is a saved snapshot of the whole project plus metadata:
- What changed — the exact content of every file at that point.
- When — a timestamp.
- Who — the author’s name and email.
- Why — a short message you write describing the change (“Fix login redirect loop”).
The “why” is the part beginners skip and seniors treasure. Six months later, the message is often the only thing that explains a strange-looking line of code.
The full history lives in a repository. A repository (or “repo”) is the project folder plus a hidden store of its entire history. With git that store is a single directory named .git at the root of your project. Delete .git and you have ordinary files with no memory; keep it and you can travel to any past commit, compare any two points, or undo work that went wrong. The repository is what turns a pile of files into a project with a past.
▸Why this works
Why did git win? Earlier systems (CVS, Subversion) kept the history on one central server — if it was down, you could not commit, and every operation needed the network. Git is distributed: every clone is a full copy of the entire history. You can commit, branch, and inspect history offline, on a plane, with no server at all. That speed and independence is why git became the default for nearly all software in the last fifteen years.
Manual copying fails at three things a VCS does for free. Concretely:
- Parallel work. Two people editing
app.jsas separate folder-copies cannot recombine their work without manually diffing line by line. A VCS merges their changes. - Authorship and reason. A folder named
final3records nothing about who changed what or why. A commit records all of it. - Recovery. Overwrite a folder and the old version is gone. In a VCS, every committed state is recoverable — you can roll back a single file or the whole project to any past commit.
These three — merge, attribution, recovery — are the entire reason version control exists.
Two ways the same week goes.
Without version control. On Monday you have site/. You add a contact form and copy it to site-form/. On Wednesday a teammate sends site-theirs/ with a new header. On Friday the client says the old footer was better. You now have three folders, no record of which footer was where, and no automatic way to combine the form, the header, and the old footer. You merge by hand, eyeballing differences, and probably introduce a bug.
With version control. The project is one repository. Each change is a commit: “Add contact form” (you, Monday), “Redesign header” (teammate, Wednesday). On Friday you ask git to show the footer from last week’s commit and restore just that file — one command, no guessing. The form, the header, and the restored footer coexist because git merged the separate lines of work. Same week, but every “what/when/who/why” question has an exact answer.
▸Common mistake
A common beginner belief is that version control is “for big teams only.” The opposite is true: even a solo project benefits immediately, because your worst collaborator is you, three months ago, who left no notes. The commit history is that note. Starting a repo costs one command and zero overhead, so the right time to start is at the project’s first file, not after the first disaster.
Which capability does a version control system provide that copying your project folder by hand does NOT?
A version control system records the entire history of a project as a chain of commits, each storing what changed, when, who made it, and why. That history lives in a repository — your files plus a hidden .git store. Compared to copying folders by hand, version control adds three things you cannot get otherwise: merging parallel work, attribution of every change, and recovery of any past state. Git is the distributed VCS the industry standardised on because every copy holds the full history and works offline. Next you will see the surprising way git stores those commits — as snapshots, not differences.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.