Undoing a change to a Ghost post
Everyone needs this eventually: you edited a post, saved, and realized the old version was better — or a bulk change went further than you meant. Ghost has a built-in answer that works for the simplest case, and a much stronger answer once your posts are files. This covers both, so you know which one you are reaching for.
What Ghost can undo on its own
The Ghost editor keeps a short revision history per post. Open the post, go into the settings menu, and you can browse recent versions and restore one with a click. For undoing a single edit you made a moment ago, this is the fastest path and you should use it.
Its limits show up quickly, though. Ghost only retains the last handful of revisions for a post, so a version from many edits ago is simply gone. The history is per-post and editor-bound, with no diffs, so you cannot see exactly what changed, and you cannot undo a change that was made across many posts at once — which is precisely the kind of change most worth undoing.
The reliable undo: local files plus git
The durable way to undo anything is to have a real history of your blog on disk. Specter syncs your Ghost posts down to a folder of markdown and back, and once that folder is under git (see version control for your Ghost posts), every committed state is recoverable — with no ten-revision ceiling and full diffs.
To undo recent, unsaved-to-git changes to the whole folder and return to your last good commit:
git checkout .
To undo a change to one specific post, restore just that file from an earlier commit. Find the commit you want with git log, then:
git checkout <commit> -- posts/the-post-you-broke.md
That brings back the earlier version of that single post as a real markdown file. Read it, confirm it is the one you wanted, and let Specter sync it back up — its dry-run preview will show the post updating on Ghost before anything goes live, and if you also edited it in Ghost meanwhile, Specter prompts you about the conflict rather than overwriting blindly.
Build the habit before you need it
The catch is that git can only restore what you committed. The undo you will be grateful for is the commit you made before a risky edit. So the rule that runs through all of this is: commit first. Snapshot the folder before you hand it to an AI tool or run a script, do the work, read the diff, and sync. Then “undo” is never a panic — it is one command.
If you have not set the folder up for history yet, start with keeping a markdown backup of your blog and putting it under git. Together they turn “I wish I could undo that” into something you simply do.