The problem before the tool
Before you learn any commands, feel why they had to be invented.
The setup
You're writing a report. It's taken three weeks. Forty pages. It's due tomorrow.
Late at night, you decide to rewrite the introduction. You delete six paragraphs and write new ones. You save the file. You close your laptop.
The next morning, you reread what you wrote. The new introduction is worse. Much worse. You want the old one back.
Stop here. Before reading further — what would you do next time to avoid this?
The instinct
Most people arrive at the same answer: make a copy of the file before changing it.
You've seen this. Everyone has. The copy strategy almost works, but it breaks in three specific ways.
Where it breaks
You can't tell what changed
You have "report-v2.docx" and "report-v3.docx." What's different between them? Was it the introduction you rewrote, or the data table you fixed? The filename doesn't tell you. You'd have to open both files and compare them, paragraph by paragraph.
Add a second person and it falls apart
Your classmate is working on Chapter 3 while you fix Chapter 1. You both started from "report-v2.docx." Now you have "report-v3-dhruv.docx" and "report-v3-ankit.docx." How do you combine them into one file without losing either person's work? Copy-paste? What if you both changed the same paragraph?
You don't know when or why
"report-backup.docx" — when did you make this? Before the introduction rewrite, or after? Was it the version you showed to your professor, or the draft before that? There's no record.
What you actually need
Think about what a real solution would look like. You need a system that:
Let's make the wishlist concrete. You need something that can:
| PROBLEM | WHAT YOU NEED |
|---|---|
| Lost the old version after saving | Save snapshots of your work at any point — and go back to any of them |
| Can't tell what changed between copies | Each snapshot has a message explaining what changed and why |
| Two people, same file, conflicting changes | A way to merge two people's work — and flag conflicts when they touch the same lines |
| No record of when or why | Each snapshot records who made it, when, and a description of why |
The name for all of this
What you just described — a system that records snapshots of your work, tracks what changed between them, knows who changed what and when, and can merge multiple people's contributions — already exists.
It's called version control.
And the most widely used version control tool in the world — the one used by nearly every software team, open-source project, and tech company on Earth — is called Git.
What Git is not
Before we go further, let's clear three common confusions:
Git is not GitHub
Git is a tool that runs on your computer. GitHub is a website that stores Git repositories online and adds collaboration features (pull requests, issues, teams). You can use Git without GitHub. You can't use GitHub without Git.
Git is not just for code
Git works on any text file — code, documentation, configuration, even this guide you're reading. It's less useful for binary files (images, PDFs, .docx) because it can't show you the difference between two versions line-by-line.
Git is not a backup service
Git stores history, but it's not designed to back up your entire computer. It tracks deliberate snapshots of a specific project. Each snapshot is one you chose to make, with a message explaining why.
The mental model
Here's the simplest way to picture what Git does:
Each circle is a snapshot (Git calls it a "commit"). Each has a message, an author, and a timestamp. You can jump back to any of them.
In the next chapter, we'll look at exactly how Git stores these snapshots — and why it's smarter than just copying files.