Git: the undo that makes AI edits safe

A tool that works this way, opening and rewriting your files directly instead of handing you code to paste, is called an agent, the word used from here on. The fear is reasonable, and git, the change-tracking tool under every serious software project, turns that handoff into a calm decision instead of a gamble.

Code is just text files in folders

A codebase (you will also hear repo or repository) is a folder holding more folders and files, and the files hold text: some code, some configuration (the settings a project runs with), some documentation. When an agent edits your code, it opens text files and changes the text, the same act as you editing a document, only faster and in more places at once. You will never read most of those files, but because everything is a file, everything can be copied, compared, and restored.

Git is undo for the whole project

You have managed versions by hand before, in a folder that looked something like this:

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

Filenames are the only version control a plain folder offers, and git is the engineered answer to the same need.

Git is undo for an entire project. It records every change to every file, by anyone, for the life of the project.

That record turns into everyday moves.

• Save point. Git calls it a commit: a snapshot of every file at one moment, stamped with a one-line note saying what changed.
• Branch. A separate line of save points for experiments, like duplicating a slide deck before a risky redesign: keep the result or discard the copy, and your main line is untouched.
• Restore. Roll a file, or the whole project, back to any save point, so recovery is one deliberate step, not an afternoon of reconstruction.

None of this involves typing commands: git has a prickly command line, but your tool runs it for you, so you ask for outcomes, "make a save point before you start," "put everything back," and the right command runs.

What the history actually looks like

Here is the history of the running-club site from the opening scene, printed the way git itself prints it (the command is git log --oneline):

f8e2a1d Fix pace calculator rounding
4c7b93e Agent session: add pace calculator, 14 files changed
9b1d442 Save point before agent session
d3f10ba Set up the running club site

Git lists newest first, so read it bottom up. Each row is one commit: the code on the left is the ID git gave that snapshot, and the note answers "what changed?" The rows that matter most tonight are 9b1d442, the save point taken before the agent started, and f8e2a1d at the top, the fix that closed the session. Between them sits the agent's entire fourteen-file change, one row you can compare against or step back behind.

That row is only worth something if you can return to it. The fix worked here; if it had not, you would have said "put the project back to before the agent session," and your tool would have run one command against that row's ID:

git reset --hard 9b1d442

Afterward, the folder matches that save point: the files the agent created are gone, the files it edited hold their pre-session text, and the schedule page renders again. The two newest rows drop out of the history; the project stepped back behind them.

Why a save point matters more when an agent is editing

You edit at human speed and remember roughly what you touched; an agent modifies files faster than you can read its plan, and a long session reaches corners you have never opened. You cannot review every line as it changes; Review what the AI built covers checking the work without reading all of it.

Make a save point before the agent works. Once it exists, the worst case for your files is restoring and retrying with better instructions.

That habit put the row Save point before agent session in the printed history. We take save points several times an hour when we build, so a mistake, ours or the agent's, only costs the work since the last one.

Your tool already makes checkpoints, so why learn git

The strongest objection is new: serious coding tools now checkpoint agent sessions on their own. Claude Code can rewind a session to an earlier state, and other tools keep similar checkpoints, so the save point you were just told to request often already exists. Why learn git?

A checkpoint records what the agent changed, inside one tool, for roughly one session; git lives in the project folder and covers every change for the project's whole life.

• Checkpoints stay behind when you switch tools. The git history travels inside the folder to whatever tool comes next.
• Checkpoints cover the agent's edits, not yours. Change a line yourself and no checkpoint marks it; git records it like any other change.
• Checkpoints are private, the history is shared. Collaborators read the git history and hosting services publish from it; nothing else reads a tool's checkpoints.

Copying the whole folder to your desktop fails the same test: that copy is Final_v2 wearing a new name, no notes, no comparisons, no per-change record.

A checkpoint is the tool's memory; git is yours. Git survives tool switches, covers your own edits, and is the record collaborators and hosts read.

Auto-checkpoints strengthen the habit rather than replace it: let the tool take its snapshots, and still ask for the commit that outlives the session.

Git keeps the history, GitHub stores it online

You will hear git and GitHub used interchangeably, and they are different things. Git keeps the history on your machine, inside the project folder. GitHub is a website holding a copy of that history online; other sites play the same role, but most shared code sits on GitHub. The online copy is a backup, so a dead laptop costs you hardware and nothing else, and it is where collaborators and hosts pick up your project. A tool offering to push to GitHub is sending your save points up to that copy, the same local-versus-remote split from Where software lives.

Try it now

This drill takes about ten minutes and spends nothing. You arrive with the printed rows above and leave having read a real history at scale.

No setup: Open GitHub in a browser, no account needed, and search for microsoft/vscode, the public repository behind the Visual Studio Code editor. Above the file list, on the right, a clock icon with a number beside it shows the commit count; click it and the history opens, newest first. Read one screenful expecting insider shorthand, notes like fix: dispose terminal renderer; you are not there for the vocabulary but to confirm the printed structure holds at scale, every row still a note, an author, a time, and a restorable snapshot.

With your tools: In Claude Code, inside any project folder, start your next session with one request: "If this folder is not a git repository yet, initialize one, then make a commit named 'save point'." Ask for the change you actually wanted, and when it finishes, ask "show me what changed since the save point." If anything looks wrong, follow with "restore everything to the save point." Repeat that loop, checkpoint, change, review, until it is habit. Same move in Codex or Cursor: ask the chat for the save point commit first, then read the source control sidebar for every file the agent touched. If your tools are not set up, the Setup Clinic takes you from nothing to that first commit.

Chapter Summary

• Your code is text files sitting in folders, and an agent editing it is doing the same thing you do in a document, only faster and in more places at once.
• Git is undo for the whole project: it records every change to every file and lets you step back to any earlier state.
• The moves are the save point (a snapshot with a one-line note, called a commit), the branch (a separate line for experiments), and restore (roll a file or the whole project back).
• A history is rows you can read: an ID, a note, newest first, and any row can be restored with one request to your tool.
• You never have to type git commands; you ask your tool for the outcome you want, and it runs the right command.
• Make a save point before an agent works. After that, the worst case is restoring and retrying with better instructions.
• Your tool's automatic checkpoints are its own session record; git is yours, surviving tool switches, covering your own edits, and serving as the record collaborators and hosts read.
• Git only protects what lives in the project folder: live databases, sent emails, and moved money are not files, so an agent needs hard limits too.
• Git keeps the history on your machine, and GitHub stores a copy online, which turns a dead laptop into an inconvenience instead of a disaster.
• Save points cover safety on your own machine. The next problem is that a project that runs perfectly for you can still break the moment it runs anywhere else, which is where Environments: why it works on your machine and breaks online picks up.

Sources

• Business Insider and Fortune reporting on the Replit coding agent deleting a live production 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).