Why 'final-v2-really-final' goes wrong
Almost everyone who makes things on a computer has had a folder that looked roughly like this: 'quote.docx', 'quote-new.docx', 'quote-final.docx', 'quote-final-v2.docx', 'quote-final-v2-really-final.docx'. With a website or a script it goes exactly the same way: 'index.html', 'index-old.html', 'index-new-final.html' — or you copy the whole folder and keep 'project', 'project-copy' and 'project-that-works' side by side.
That is not sloppiness. It is a healthy instinct: you want to be able to fall back on something that worked. It is just that the way you are doing it is unreliable. After a week you no longer know the difference between final and final-v2, why you made that copy in the first place, or which of the five is the one you sent to the client.
Three problems you probably recognise
The first is being afraid to change anything. As soon as something works, you no longer dare to touch it. You want to try an idea, but the risk of breaking things weighs heavier — so you leave it. Your project stalls because you have no way back.
The second is not knowing what you changed. Something worked yesterday and does not work today. Somewhere between those two moments sits the one change that broke it, but which one? Without a history you can only guess and search everywhere at once.
The third shows up the moment someone joins you: two people working in the same file. You email versions back and forth, someone accidentally carries on in the old one, and half a day of work is gone. Once you collaborate, loose copies are guaranteed to become a problem.
What version control offers instead
Version control means you do not keep loose copies of your project, but its history. At moments you choose, you record: this is what it looks like now. Such a recorded moment is called a commit, and you write a short description to go with it.
From then on you have a timeline. You can see what changed between two moments, down to the line. You can go back to how things were yesterday. You can try something on a side track and throw it away if it comes to nothing, without your main version noticing. And you can work on the same project with others without overwriting each other's work.
The tool that does this is called Git. It is free, it runs on your own computer, and it is what practically every software company in the world uses. You do not need to be a programmer: in this course you learn the handful of commands you actually use in practice.
git log --oneline 3f9a1c2 Update prices for 2026 8b2e7d4 Contact form now actually sends email a1c5f90 First version of the website
Above is what you will be looking at yourself by the end of module 2: the history of a project. Each line is one recorded moment, with a short code and your own description. You do not need to be able to do this yet — just notice what it gives you. Instead of five folders with cryptic names, you have one project with a readable story behind it.
- Find a folder on your computer with several versions of the same thing (documents, a website, a project). Almost everyone has one.
- For each version, can you still say how it differs from the previous one, and why you made it? Write down where you have to give up.
- Now choose one project to use for this course. Something real, not too big, and made of text files: a website, a script, a folder of notes in .md or .txt. Do you mostly work in Word or PDF? Then pick something else for this course — the first point below explains why.
- Make one backup copy of that project somewhere safe. From lesson 1.3 onwards we will be working inside it, and it is reassuring to know that nothing can go wrong.
Stuck?
- I do not work with code — is this for me? Yes, the way of working is exactly the same. Just be careful what you pick as your course project. Git stores every file, but it can only compare text: code, HTML, .md, .txt, configuration. A Word or PDF file is a packed file on the inside; Git stores it perfectly well, but to the question 'what changed?' it says no more than 'binary file modified'. So for the exercises in modules 2, 3 and 5 you need a project made of text files.
- I already use a cloud service that keeps versions. Isn't that enough? It helps against accidental overwriting, but it saves everything automatically, without any explanation of why something changed. Git records at the moments you choose, with your description — and that is exactly the difference when you need to trace something.
- Isn't Git mainly for large teams? It is just as useful on your own. Most of this course needs no second person; collaboration only arrives in module 5.
- Do I need to install anything yet? Not yet. Lesson 1.2 explains the difference between Git and GitHub first; in lesson 1.3 you install Git.
- Which three problems does version control solve that loose copies do not?
- In your own words, what is a commit?
- Why is a cloud service that saves versions automatically not the same as version control?