Resolving a sync conflict
A sync conflict sounds alarming the first time you see one, but it is actually the safety feature doing its job. It means a single post changed in two places since the last sync — you edited it locally and it changed in Ghost — and Specter has noticed that blindly syncing would have to throw one of those versions away. Rather than guess, it stops and asks you. This guide explains what triggers a conflict and how to resolve one without losing work.
What a conflict actually is
Specter does two-way sync: edits you make to local markdown push up to Ghost, and edits made in Ghost pull down to your files. To do that safely it keeps track of when each post last changed on each side. Most of the time only one side has moved — you edited the file, or someone edited the post in the Ghost editor — and Specter simply carries that change across. A conflict is the case where both sides moved since they were last in agreement. Now there are two competing versions of the same post, and there is no way to keep both as a single post without a decision.
This is exactly the situation where a naive sync tool quietly loses your work. “Last write wins” is how an afternoon of local editing disappears because a background pull overwrote it, or how a colleague’s fix in Ghost gets stomped by your older local copy. Specter refuses to make that call for you. Instead of silently overwriting either side, it surfaces the conflict and hands you the decision.
The prompt and your three choices
When Specter detects a conflict, it tells you which post is affected and offers three ways to resolve it:
Keep local takes the version on your disk as the winner and pushes it up to Ghost, replacing the remote copy.
Keep remote takes the version in Ghost as the winner and pulls it down, replacing your local file.
Skip leaves both versions exactly as they are and does nothing for now, so you can go look at the two copies before deciding.
The right choice depends entirely on which edit you want to keep, which is why Specter asks rather than assumes. If you are not sure, skip is the safe answer: nothing is overwritten, and you can open the local file and the Ghost post side by side, see what differs, and resolve it on the next sync once you know which one you want.
A practical tip for when you genuinely want to merge both sets of changes rather than discard either: keep the remote version, let it pull down to your file, then re-apply your local edits on top of the now-current post and sync again. That way you start from whichever copy is freshest and add the rest by hand, instead of forcing the tool to pick.
Avoiding conflicts in the first place
Conflicts are normal and harmless when they happen occasionally, but you can keep them rare. The simplest habit is to not edit the same post in the Ghost web editor and locally at the same time — pick one place to be the source of truth for a given post while you are working on it. Before a big local pass, such as an AI edit across many posts or a bulk SEO update, it helps to sync first so both sides start in agreement, then do your work locally, then sync back.
It is also worth leaning on the dry-run preview before a large sync: it shows you exactly which posts would be created, updated, or flagged as conflicts before anything is written, so you see any conflicts coming as a list rather than one prompt at a time. And if you keep the synced folder under git, as described in version control for your Ghost posts, you always have an earlier snapshot to fall back on no matter which way you resolve. The whole design here points one direction: your edits are never one click away from being lost.