The Folder Full of final_v2_FINAL

Everyone invents the same system before they meet Git. You are about to change something that currently works, you get nervous, and you copy the whole folder first. A week later the desktop holds site, site-backup, site-backup-2, site-FINAL, and — because the final version needed one small fix — site-FINAL-v2.

It is not a stupid system. It comes from a completely correct instinct: I want to be able to go back. The problem is that it only preserves one thing about the past, and throws away everything else you will need.

What the copy-the-folder method actually keeps

Open site-backup-2 and you can see what the project looked like at some point. That is genuinely useful, and it is where the usefulness stops.

You cannot tell when that copy was made, beyond whatever the file dates say. You cannot tell why it was made — what you were about to try, or what had just gone wrong. And if anyone else has touched the project, you cannot tell who made which copy. Six weeks later, standing in front of five folders, the only honest answer to "which one is the live version" is a guess.

The four questions

Every serious question you will ever ask about a project's past is one of four: what changed, when it changed, why it changed, and who changed it. Hold on to that list — it comes back at the end of Chapter 3, when you can answer all four in about ten seconds.

A concrete version, which becomes this book's running example two topics from now. You are building a website for your neighbourhood birdwatching club. Right now it exists as three folders on the desktop, two of them with the wrong meeting time in the header, and the club meets on Thursday.

Undo has a ceiling

The other tool everyone reaches for is the editor's undo, and it is excellent until it is not. Close the file and the undo history usually goes with it. Restart the machine and it certainly does. Undo also works in the wrong unit: it steps back one keystroke or one edit at a time, but the thing you want to undo is usually "the idea I had on Tuesday", which was forty edits across three files.

So you fall back on the folder copy, which is only as recent as the last time you remembered to make one — usually just before something scary, which is exactly when you were least likely to remember.

Two people, one file

Now add a second person. You email them the project, they fix the contact page and email it back, and in the meantime you have rewritten the home page. There are now two versions, each containing work the other does not have, and no mechanical way to combine them. Someone opens the other person's copy, copies their own changes across by hand, and hopes nothing was missed.

Notice what kind of problem that is. Nothing has broken technically; the files are all fine. The problem is that two histories exist and there is no rule for joining them. That is the problem branches and merging solve in Chapter 6, and it does not have a folder-shaped answer.

What a real solution would have to do

Before meeting the tool, it is worth writing the requirements yourself. A system that fixed all of this would have to record every version automatically rather than when you remember; attach a reason to each one in your own words; let you read any past state without disturbing the present one; and let two people change the same project without either of them losing work.

That list is not a description of Git that you are supposed to take on faith. It is the specification Git was built against, and every command in the next ten chapters is an answer to one line of it. When something later feels arbitrary, this page is usually the reason it exists.