What Is Version Control?

The final_v2_REAL Problem
Snapshots, Not Copies
What Version Control Gives You
Git: The Tool
GitHub: The Website
The Words You'll Hear
What You'll Build
Try It Yourself

1. The final_v2_REAL Problem

You've probably seen a folder like this — maybe on your own computer:

report.docx
report_v2.docx
report_v2_edited.docx
report_final.docx
report_final_v2.docx
report_final_v2_REAL.docx

Everyone does this, because everyone has learned the hard way that overwriting a file can destroy work you later want back. But this system has real problems:

Which one is the latest? The names don't tell you for sure.
What changed between them? You'd have to open two files side by side and compare by eye.
Why did it change? Nobody wrote that down.
What if two people edit it? Someone emails report_final_dara.docx, someone else sends report_final_sophea.docx, and now a human has to combine them by hand.

Now imagine a software project with hundreds of files, five developers, and changes every hour. Copying folders stops working almost immediately. That's the problem version control solves.

2. Snapshots, Not Copies

A version control system records the history of a project as a series of snapshots. Each snapshot captures what every file in the project looked like at one moment, along with:

who made it
when they made it
a short message explaining why

You keep working in one normal folder with normal file names — no _v2, no _final. Whenever you reach a point worth remembering, you tell the version control system to take a snapshot. The history lives in the background, out of your way, until you need it.

 snapshot 1        snapshot 2           snapshot 3
"Add home page" → "Add about section" → "Fix typo in title"
  Dara, Mon         Dara, Tue             Sophea, Wed

It's like the save points in a video game: you can keep playing forward, but you can always go back to any point you saved.

3. What Version Control Gives You

With every change recorded, a lot of things become easy:

Undo anything. Broke something? Go back to yesterday's snapshot. Deleted a file by accident? Bring it back.
See exactly what changed. Compare any two snapshots, line by line.
Understand why. Every change has a message and an author. When you find a strange line of code a year from now, you can find out who added it and why.
Experiment safely. Try a risky idea on the side without touching the working version. If it fails, throw it away.
Work together. Several people can change the same project at the same time, and the system combines their work — and tells you clearly when two changes collide.
Back up your work. Copy the whole history to another computer or to the internet, so a dead laptop doesn't mean lost work.

4. Git: The Tool

There have been many version control systems over the years, but today one has won almost completely: Git.

Git was created in 2005 by Linus Torvalds — the same person who created Linux — to manage the Linux kernel's source code, which thousands of developers change at once. It had to be fast, reliable, and work well for huge teams. It turned out to be great for small projects too.

A few things to know about Git:

It's a program on your computer. You install it, and you mostly use it by typing commands in a terminal, like git commit.
It works offline. Your project's entire history is stored on your own computer, inside a hidden folder called .git. You don't need the internet to save snapshots, read history, or undo things.
It's distributed. Every copy of a project contains the full history. There's no single computer that the project depends on.
It's free and open source.

5. GitHub: The Website

People often mix these two up, so here's the difference in one line:

Git is the tool that tracks history. GitHub is a website that stores Git projects online and adds tools for working together.

GitHub gives you:

a place to back up your Git projects on the internet
a way to share them — publicly with the world, or privately with your team
pull requests, where teammates review each other's changes before they're accepted
issues, a to-do list and bug tracker for each project
free website hosting with GitHub Pages (you'll use it in the final chapter)

GitHub is not the only option. GitLab and Bitbucket do the same job, and some companies run their own Git servers. Because they all use Git underneath, everything you learn in this series works with all of them. GitHub is simply the most popular, and it's where most open-source projects — and most developer portfolios — live.

Git works perfectly well without GitHub. GitHub doesn't work without Git.

6. The Words You'll Hear

You'll meet each of these properly in later chapters. For now, just get familiar with the names:

Word	Meaning
Repository (repo)	A project tracked by Git — your files plus their whole history
Commit	One snapshot in the history, with an author, a date, and a message
Branch	A separate line of work, so you can try things without touching the main version
Merge	Combining the work from one branch into another
Remote	A copy of the repository somewhere else, usually on GitHub
Push	Sending your new commits up to the remote
Pull	Bringing new commits down from the remote
Clone	Downloading a full copy of a repository, history included
Pull request (PR)	A request on GitHub to merge your branch, so others can review it first

7. What You'll Build

Instead of separate toy examples, this series builds one project from start to finish: a small personal website called my-site.

In chapters 3–7 you'll build it on your own computer, using Git to save snapshots, read history, undo mistakes, and work on branches.
In chapters 8–10 you'll put it on GitHub and practise the workflow real teams use.
In chapter 11 you'll publish it on the internet, for free, at an address like https://<your-username>.github.io/my-site/.

You don't need to know HTML. The pages are tiny, and every line is given to you. (If you want to make it beautiful afterwards, that's what HTML & CSS Fundamentals on the roadmap is for.)

8. Try It Yourself

There's nothing to install yet — that's the next chapter. Instead:

Find a _final_v2 folder. Look through your Documents or Downloads. Do you have files with version numbers or "final" in the name? That's manual version control.
Look at a real project's history. Open github.com/git/git — the source code of Git itself, stored in Git, hosted on GitHub. Near the top, click the commits count (it has a clock icon). Every entry is one snapshot, with an author, a date, and a message. There are tens of thousands.
Open one commit. Click any commit message. Lines in green were added, lines in red were removed. That's exactly what you'll be reading in your own projects soon.

Next, let's install Git and set it up.