Saving Your Work

You have been building tools. You have fixed errors. You have run scripts that do real work. Now there is one more habit to add — and it will protect everything you have built.

This lesson is about saving your work in a way that gives you a time machine: any version that ever worked is recoverable. Any experiment gone wrong is reversible. You cannot permanently break a project that has commits.

What Git Is (and Is Not)

Git is a tool that takes snapshots of your project. That is it. Each snapshot is called a commit, and each commit has a label you write yourself.

Think of it like saving a document in Google Docs, but better: instead of one auto-save, you choose exactly when to save and you write a note describing what is in each version. If you decide last Tuesday's version was better, you can go back to it.

Git is not:

• A backup service (though it works like one)
• A hosting platform (GitHub is separate — git is the local tool)
• Something that requires a deep technical background to use

You need exactly four commands. They handle 90% of what you will ever need to do.

The Four Commands

Let's walk through each one in plain terms.

git add . && git commit -m "message" This is your save command. git add . tells git which files to include (the dot means all of them). git commit -m "message" takes the snapshot and attaches your label. The message can be as simple as "fixed the date filter" or "added email output." Write something you would find useful in a week.

git status Shows you what has changed since your last commit. Which files were edited, which are new. Run this whenever you want to check where you are before committing. It never changes anything — it just shows you the current state.

git checkout -b experiment Creates a new parallel copy of your project called "experiment" (or whatever you name it). Everything in your working version is preserved exactly as it is. Now you can try something risky on the branch. If it works, you merge it in. If it breaks, you switch back to main and the original is untouched. To switch back: git checkout main. Your working version is exactly as you left it. (Merging a successful experiment back in is a later skill — when you get there, ask Claude for the steps.)

git restore . Throws away all unsaved changes since your last commit. Use this when you have gotten into a tangle and want to start over from the last working snapshot. This is irreversible — it discards everything since the last commit — so only use it when you are certain.

Version History as a Timeline

The diagram above shows what a healthy version history looks like in practice. Each commit is a node on the timeline. When version four broke things, going back to version three was a single command. The broken version is not deleted — it is just not the current one.

This is what "undo without fear" means. You cannot lose a version you committed. The worst case is that you need to jump back to an earlier snapshot, which is a single command.

When you need the time machine, here is the actual move. First, see your snapshots:

git log --oneline

That prints one line per commit — a short ID followed by the label you wrote. Find the version you want back, then:

git restore --source a1b2c3d .

(replacing a1b2c3d with the short ID from the log). Your files become that version again — and nothing in your history is deleted, so you can change your mind. If anything about this feels uncertain in the moment, paste your git log --oneline output to Claude and say which version you want back; it will give you the exact command.

A Simple Practice

When you sit down to work on your script:

1. Run git status to see where you left off
2. Make your changes and test them
3. When it works, run git add . && git commit -m "what you changed"
4. If you want to try something risky, run git checkout -b experiment first

That is the full routine. Most sessions involve two or three commits. Sometimes one. Occasionally none if you spent the session exploring and nothing is ready to save yet.

Starting a New Project

If your project folder does not have git yet, initialize it with one command:

git init

Run this once in the project directory. After that, all four commands work as described. You only need git init once per project.

Getting Git Installed

If you do not have git installed yet, Claude can walk you through it — tell it which operating system you are using and ask for the installation steps. On most Macs it is already present. On Windows, the most common route is to install "Git for Windows" from git-scm.com.

What You Now Have

You have a tool. You have the debug loop. You have version control. The next lesson is the last one in this track — it covers how to share and polish your tool, and where to go next.