4.1
What Git Actually Is
Why this exists
Next week you build something real, and the week after you start changing things other people depend on. Neither of those is safe until you can undo.
This is also the topic with the worst reputation in the whole course. Git has a reputation for being hard, and that reputation is about using it from memory, which you are never going to do. The idea underneath it takes ten minutes.
The idea
Cmd+Z remembers this session. Git remembers every version of everything, forever.
That's the gap it fills. Undo is one file, this session, gone the moment you close the window. Git is save points for an entire folder, kept permanently, that you can return to whenever you like.
Three words and you have it:
| Word | Means |
|---|---|
| Repository | A folder with history switched on. Usually shortened to "repo". |
| Commit | A save point. A snapshot of the whole folder, plus a note about why. |
| History | Every commit, in order, all still there |
Turn it on for a folder and from that moment it watches. Every time you commit, it stores the exact state of everything and what you said about it. Later you can look at any of those states, compare them, or go back to one.
The consequence worth internalising:
Once something is committed, it cannot be lost. Not by a bad edit, not by deleting the file, not by Claude changing forty things at once. The save point is still there.
That's what changes what you're allowed to do. Right now you're being careful because a mistake is permanent. With commits behind you, a mistake is an inconvenience — you go back to the last good state and try again. Careful stops being the strategy, and you can move considerably faster.
And you don't need to memorise commands. This is the part nobody says out loud. Git has a genuinely awkward interface, built for people using it forty times a day. You aren't. You'll ask Claude — "commit this with a message about what we changed", "put that file back how it was this morning" — and it runs the commands.
Which is why this level teaches the concepts rather than the syntax. You need to know what's possible, precisely enough to ask for it. Knowing that "go back to how it was before we started" is a thing you can request is the whole skill. The command is trivia.
One boundary to hold from the start: git tracks your files, not your secrets. Passwords, API keys and tokens must never be committed, because history is permanent and that cuts both ways — a key committed once stays in the history even after you delete the file. That's 6.8, and it's why this warning arrives now rather than then.
Do
Use the real project from Level 3, not sandbox.
- Ask Claude:
set up version control in this folder and explain what you just did. - Ask:
what's the current state — what's being tracked and what isn't?Read the answer. - Ask it to make a first commit with a message describing where the project is right now.
- Ask:
show me the history.You should see exactly one entry. That's your first save point. - Now break something on purpose. Delete a file you'd miss. Badly mangle another.
- Look at the damage in Finder. Sit with it for a second.
- Ask:
put everything back to the last save point. - Confirm in Finder that both files are back to normal.
- Write one line in
undo.md: what you broke, what you asked for, and whether it worked.
Step 6 matters more than it sounds. You need a moment of "that would have been bad" immediately before the recovery. That's what converts this from a concept you've read into a tool you'll reach for.
Done when
Never do
Never commit passwords, API keys or tokens. History is permanent. Deleting the file later does not remove it from the history — the key is still in there and still readable. If it ever happens, tell me immediately and treat that key as compromised, because it is.