You promised the club a pace calculator, and at 10:14 pm you hand the job to your agent. The site already runs on your laptop with its home, trails, RSVP, and tidy pages. The agent proposes touching fourteen files, four of them new, and you have never opened most of the rest. You approve, and filenames scroll past faster than you can read them. Halfway through, the trails page comes up blank. Your hand goes to Ctrl+Z, and the shortcut cannot help. Undo lives inside one editor window and covers your own last keystrokes in one file; nothing on your keyboard reaches across fourteen files being rewritten. The whole project was one save point from safe, and you had not made it.

Undo for the whole project, not one file

Git is the change-tracking program that sits under most software projects. It keeps every version of every file, with a one-line note on each version, and it can bring any of them back. The undo you reached for covers one file; git covers every file in the folder for the life of the project.

Without it, versions sit in filenames, in a folder that looks like this:

Final.docx
Final_v2.docx
Final_FINAL.docx
Final_FINAL_use_this_one.docx

No note says what changed between two copies; git keeps that note, and it comes switched on in most project folders an agent creates.

A repository is a project folder that git watches; builders shorten it to repo. Your running-club folder becomes one the moment git is switched on inside it, and from then on git notices every edit, yours or the agent's.

A snapshot, a side track, and a rewind

A commit is a snapshot of every file at one moment, with a one-line note saying what changed, and in this course we call it a save point. Like a save point in a game, it marks a spot you can return to, so a bad run costs you only the play since then.

The history is the list of save points, newest first, with each note beside its snapshot. A branch is a separate line of save points for an experiment, like a side track off a railway's main line. The main line stays untouched until you keep the result or abandon the track.

To restore means to put a file, or the whole project, back to a save point. Here is the running-club history as it would look with a save point made before the agent session.

Restore to the save point before the agent session and the two newer points drop off the line, though git still keeps them for a while if you change your mind. That is fine: you chose an earlier state, and the next save point you make starts the line again from there.

Git is undo for the whole project. It records every change to every file, so any earlier version can be put back.

Ask the agent what changed

Before you put anything back, ask what the session did. A diff is the before-and-after of one change, the lines removed and the lines added, file by file. Here is the one for the page that went blank.

You never type a command to get this view; you ask the agent, and it prints one card like this for each file it touched. With fourteen cards to read, ask for the list of changed files first and open only app/trails/page.js, the one behind the blank page.

These are the three requests you type to the agent, in the order you use them:

Before the session: "Make a save point before you start; call it 'before pace calculator'."
When something looks wrong: "Show me what changed since the save point."
To rewind: "Put the project back to the save point 'before pace calculator'."

The agent turns each request into the right git command and runs it in the terminal.

Make the save point first

An agent edits faster than you can read its plan, and in a long session it reaches files you have never opened. You cannot review every line as it scrolls past, so the safety has to come from before the session.

Make a save point before an agent edits anything. After that, the worst case is putting the project back and asking again with better instructions.

When the trails page went blank, you typed the third request and the agent put the project back: the files it created are gone, and every edited file holds its earlier text. Then you ask again, with one more instruction: leave app/trails/page.js alone.

The objection: my tool can already rewind a session

Claude Code, the AI coding tool we use in this course, records the state of your files as a session runs and can rewind to an earlier point. Other coding tools do the same. A checkpoint is a tool's own record of one session, the tool's private notes on what it changed. So why learn git at all?

A checkpoint records what one tool changed in one session; git records what the whole project looked like at every save point, whoever made the change.

Checkpoints stay with the tool when you switch tools; the git history travels inside the folder to whatever tool comes next.
Checkpoints cover the agent's edits but not yours; git records a line you changed like any other change.
Checkpoints are private to the tool; the git history is what collaborators read and what hosting services use to put your site online.

A tool's checkpoint records one session inside one tool; git is the project's permanent record, and it is what collaborators and hosting services read.

Git on your laptop, and a copy online

Git keeps the history on your laptop, inside the project folder. GitHub is a website holding a copy of your history online, a backup shelf for the whole project. Other websites do the same job, but most shared code sits on GitHub. This is the local and remote split from Where software lives, applied to your own history.

To push means to send your save points up to that online copy. When the agent offers to push after a session, say yes: a dead laptop then costs you hardware and nothing else. To clone means to copy the whole history down onto another machine, so a new laptop or a collaborator starts with every save point you ever made. In Environments: why it works on your machine and breaks online, you put the site the club uses onto the internet from that same online copy.

Try it now

This drill takes about ten minutes; the no-setup path costs nothing, and the tooled path costs a few cents of usage.

No setup: Open GitHub in a browser and search for microsoft/vscode, a large public repository; no account is needed. Above the file list, a clock icon with a number beside it shows how many save points the project has. Click it to open the history, newest first, one row per save point with its note, author, and time. Expect insider shorthand in the notes.

With your tools: Open Claude Code in the running-club folder and type: "Make a save point before you start; call it 'before pace calculator'." The agent switches git on if the folder needs it and reports the save point by its note. Ask for a small change to the trails page, then type "Show me what changed since the save point" and read the diff for app/trails/page.js. Then type "Put the project back to the save point 'before pace calculator'", refresh the page, and watch your change vanish. In Codex or Cursor, the same three requests work, and a side panel lists every file the agent touched. If nothing is installed yet, The Setup Clinic gets you to that first save point.

Either way, add one line to the idea file, and on the tooled path keep a first save point in the running-club folder. The line: "Before every agent session: save point. To undo: put it back to [name]."

Chapter Summary

Git is undo for the whole project: it records every change to every file, so any earlier version can be put back.
A repository is a project folder that git watches, and a commit, which we call a save point, is a snapshot of every file at one moment with a one-line note. The history is the list of save points, newest first; a branch is a side track for an experiment; to restore means to put a file or the whole project back to a save point.
A diff is the before-and-after of one change, lines removed and lines added, file by file, and you ask the agent to show it rather than typing a command.
Make a save point before an agent edits anything; after that, the worst case is putting the project back and asking again with better instructions.
The three requests you type are: make a save point and name it, show me what changed since the save point, and put the project back to the save point.
A save point covers only files in the project folder. It never covers the records real users have entered, the emails a tool has sent, or the money a payment integration has moved, so an agent that can touch any of those needs limits too.
A tool's checkpoint records one session inside one tool; git is the project's permanent record, and it is what collaborators and hosting services read.
Git keeps the history on your laptop, GitHub holds a copy online, push sends save points up, and clone copies the whole history down.
You now hold a first save point in the running-club folder, and the idea file carries the rule: save point before every agent session.
Next, Environments: why it works on your machine and breaks online puts the site online for the club and shows why a project that runs on your laptop can still break there.

Sources

Business Insider and Fortune reporting on the Replit coding agent deleting a startup's database (July 2025).
Git documentation, git-scm.com (last verified July 2026).
GitHub documentation on commits and viewing a repository's commit history (last verified July 2026).
Anthropic Claude Code documentation on checkpoints and rewinding a session (last verified July 2026).

Git: the undo that makes AI edits safe