What is Git actually doing?

You are working on a project. It reaches a state you do not want to lose, so you copy the folder. A week later you do it again. Soon your desktop holds project, project-old, project-final, project-final-2-REALLY. Every developer on earth has done this. It works — until the day you need to answer one simple question: what exactly changed between these two versions?

With copied folders, answering that means opening files side by side and squinting. Git was built to answer it instantly. The price is one habit: when your work reaches a state worth keeping, you tell git to save it, with a short label describing what it is.

When you tell git to save, it does not save one file — it photographs everything, all at once. That photograph is called a commit. A commit remembers the exact content of every file in your project at that moment, plus the label you gave it, plus the time, plus who made it.

Think of a video game. Before a hard level you save; if things go wrong you load the save and nothing is lost. A commit is that save point, with two upgrades. First, all your save points are kept forever, in order, as a chain — git calls this chain the history. Second, each one carries a message you wrote, so you can find the exact moment anything happened.

Git keeps every commit inside one hidden folder named .git, sitting inside your project folder. You will almost never look inside it — it is a packed archive, not meant for humans. What matters is knowing it exists: your entire history lives in your project, travels with your project, and needs no internet.

This is also the precise line between git and GitHub. Git is the tool on your computer; committing is completely offline. Sharing your photographs with the world is a separate, later step — and the website where that happens is GitHub. The last courses of this series cover exactly that split.