How to Back Up Before Claude Code Edits (Git Checkpoints for Total Beginners)

You're about to hand Claude Code a real task, and a small voice says: what if this goes wrong? Good instinct. The smart move is to save a restore point before you let it loose, not to go hunting for one after. Here's the part most beginners don't realize: you can do that in about 30 seconds, and you don't need to know a single git command.

Let's start with why this matters, then the exact words to type.

Why "back up first" is the whole game

Claude Code edits the real files on your computer, not copies. When it changes, moves, or deletes something, it's happening to your actual project, live. That's what makes it useful, and it's also why a bad moment is a real change, not a preview you can dismiss.

So the cheapest safety habit in all of Claude Code is this: before a risky task, take a snapshot you can return to. If the result is great, you ignore the snapshot. If it goes sideways, you roll back to it in one step. The snapshot costs you nothing and removes almost all the fear.

The fastest snapshot is a git checkpoint.

The 30-second backup: a git checkpoint (no git knowledge needed)

A "checkpoint" is just a saved snapshot of your project at this moment, one you can come back to. In git, it's called a commit. The good news: you don't have to learn git to use it, because Claude can set it up and run it for you. Type this in plain English:

"Set up git for this project if it isn't already, then commit a checkpoint right now so I have a safe point to return to."

That's it. Claude initializes git if needed and saves a snapshot of every tracked file. You just made a backup without typing a git command.

When you want to go back, you ask the same way:

"Roll the project back to the last checkpoint we made, and explain what you're about to do before you do it."

You're using git as an undo button, in plain English, with Claude doing the typing. (The "explain before you do it" part is worth keeping in every risky request. It lets you catch a wrong move before it runs.)

The before-anything-risky routine

Make this a reflex. Right before you hand Claude a big or destructive task, ask for a checkpoint. The tasks worth checkpointing first are the ones that change a lot at once:

• "fix the build" or "make the tests pass"
• "clean this up" or "reorganize these files"
• anything with a delete in it
• a big refactor across many files

These are exactly the moments Claude reaches for sweeping commands like rm -rf, so a fresh checkpoint right before them is the cheapest insurance you'll ever buy. Take the snapshot, then give the task.

What a checkpoint does NOT back up (read this part)

A git checkpoint is great, but it has a blind spot, and it's the one that bites people. A commit only saves files git is tracking. Two kinds of file slip through:

• Brand-new files you haven't committed yet. If you created it after your last checkpoint, there's no snapshot of it to restore.
• Git-ignored files. Your .env (the file holding your secret keys), a local database, build output, and anything listed in .gitignore are deliberately kept out of git. A checkpoint never sees them, so it can't bring them back.

Those git-ignored files are often the most painful to lose, because there's usually only one copy. This is also the blind spot behind a lot of "I had a checkpoint and still lost it" stories.

/rewind doesn't cover this gap either. /rewind (press Esc twice) only undoes Claude's own Write and Edit edits inside the current session. It doesn't track terminal commands and doesn't cover untracked files, so it's a fast everyday undo, not a backup. (Full breakdown: Does Claude Code's /rewind Undo Deleted Files?)

Close the gap: two more layers

Stack these on top of the checkpoint and the blind spot mostly disappears.

1. Turn on an automatic backup of the whole folder. This catches the files git ignores, without you remembering to do anything. On a Mac, turn on Time Machine for wherever your projects live. On Windows, turn on File History. Or keep the project inside Dropbox, Google Drive, OneDrive, or iCloud, which quietly keep older versions you can roll back to.
2. Add a copy taken before Claude acts, for the files git skips. A backup restores slowly and a checkpoint never sees your .env or local database at all. The durable fix for that exact gap is a copy of the file made the instant before Claude touches it. That's what Undeletable does: a tiny local add-on for Claude Code that saves a byte-for-byte copy of a file before Claude edits or deletes it, including the untracked files git ignores. If something goes wrong, you type /restore. It runs locally (no account, no cloud), it's a one-time $19, and it only protects from the moment you install it, so the time to add it is before the next scare, not after.

The fuller version of this whole setup is here: How to Set Up Claude Code So It Can't Delete Your Work.

The order that matters

If you do one thing before your next risky task, make a git checkpoint. If you do three, add an automatic backup of the folder and a pre-action copy for the files git can't see. Stacked together, "what if this goes wrong?" stops being a reason to hesitate. You take the snapshot, you give the task, and a bad result is a one-step rollback instead of a long bad day.

Get the checklist

Want this as a calm, do-this-then-this list you can keep on hand? Grab the free Claude Code Safety Checklist. It's the plain-English version of the setup above, and we'll email it to you so it's there the day you need it. When you want the always-on net for the files git and /rewind quietly skip, Undeletable is $19, one time, and lives quietly on your machine.

---

Related reading: How to Set Up Claude Code So It Can't Delete Your Work · How to Undo in Claude Code · Does Claude Code's /rewind Undo Deleted Files? · The free Claude Code Safety Checklist