Why did my Shopify deploy revert the merchant’s changes?

Because a theme push uploads your files over the theme’s files. Any edit made directly in the Shopify admin or theme editor since your last pull is not in your copy, so pushing removes it.

How do I tell if a live Shopify theme has changed since my last deploy?

Pull the live theme into a clean directory and diff it against the commit you last deployed. Anything that shows up is drift that happened on the store.

Should the live Shopify theme be in git?

Yes, but with the store treated as the source of truth rather than your branch. Pull the live theme on a schedule and commit what changes, so drift is recorded instead of discovered during a deploy.

Problem / Solution 8 min read

The Untracked Live Theme: Every Agency’s Quietest Risk

You have the repo. The repo does not have the store. Somewhere between them are eight months of admin edits nobody wrote down — and your next deploy will remove them.

ThemeSync Team

Published: September 2026 · Updated: September 2026

The setup that guarantees it

You take on a store that's been trading for years. There's a repo, maybe. It was last committed to whenever the previous engagement ended. Everyone treats it as the source of truth because it's the only thing that looks like one.

It isn't. The store is. And in the gap between the last commit and today, entirely reasonable things happened:

The merchant added three homepage sections for a campaign and left them in.
A reviews app injected a snippet and a block into the product template.
Someone edited theme.liquid in the admin code editor to fix a tracking script at 11pm before a sale.
A freelancer did a fortnight of work and pushed straight to the live theme.

None of that is in your repo. All of it is live and load-bearing. Your first deploy — a footer change, say — uploads your files over the theme's files and removes every bit of it.

Why this is the worst kind of incident: it doesn't error, it happens on the live storefront in front of customers, and the blast radius is invisible until someone notices the reviews widget is gone or a campaign banner has reverted. You will be told you broke the store, and technically you did.

Finding out how bad it is, before you deploy anything

This is measurable in about ten minutes, and it should be the first thing you do on any inherited store — before you write a line of code.

Measure the drift

# 1. Which theme is actually live?
shopify theme list --store client.myshopify.com

# 2. Pull it into a clean directory
shopify theme pull --theme 987654321 --store client.myshopify.com --path ./live-now

# 3. Diff it against what you believed was deployed
git --no-index diff ./repo ./live-now --stat

The output tells you which project you're actually on. Read it against this:

What the diff shows	What it means	What to do
Only `settings_data.json` and JSON templates	Merchant configuration drift. Normal and expected.	Adopt the store's version and commit it.
New snippets, or app blocks in templates	Apps have installed code.	Keep it. Removing it breaks paid apps.
Changes inside Liquid sections you wrote	Someone edited code directly on the store.	Stop. Find out who and why before touching anything.
Whole templates you've never seen	Another party did real work here.	Treat the store as the baseline. Your repo is stale.
Nothing	Genuinely in sync.	Set up tracking so it stays that way.

Do this before quoting. "Change the footer" on a tracked store is an hour. On a store with eight months of undocumented drift it's a day of archaeology first. Finding that out after you've fixed a price is how projects go underwater.

Adopting the live theme properly

The fix isn't to force your repo onto the store. It's to make the store's current state the baseline, then keep watching it.

Pull the live theme and commit it as-is. Don't tidy it, don't reformat it, don't remove the app snippets you dislike. This commit's job is to be an honest record of what was live on the day you took over.
Branch your work from that. Now your changes are relative to reality instead of to a stale memory of it.
Pull on a schedule from then on. Merchants and apps will keep changing the live theme. If that lands as a commit within the hour, it's information. If it surfaces during a deploy, it's an incident.
Diff before every deploy. Non-negotiable on a live theme. You want to know what you're about to overwrite while you can still choose not to.

The direction of truth matters

Teams that set this up and still get burned usually got the direction wrong. Development work and live-theme tracking need opposite defaults.

	Development theme	Live / draft theme
Source of truth	Your git branch	The store
Normal flow	git → theme	theme → git
Automatic direction	Push your commits	Pull and commit what changed
Deploying	Continuous, low stakes	Deliberate, manual, reviewed
Who else writes here	Nobody	Merchant, apps, other agencies

Getting this backwards — treating your branch as authoritative for the live theme and auto-deploying it — builds a machine that erases merchant edits on a timer. That's meaningfully worse than having no automation at all.

Rule that holds up: pulling from a live theme can be automatic, because it only ever records. Pushing to a live theme should always be a human decision, because it's the only direction that destroys.

Telling the client without alarming them

You've found that the live theme has drifted and nobody can account for it. That's an awkward finding, particularly if the drift is the merchant's own doing or a previous agency's.

Framing it as risk reduction rather than blame gets a much better response:

"Before I deploy anything I've taken a full snapshot of your live theme, because it's picked up changes over the years that weren't in the codebase — campaign sections, app code, a few direct edits. That's completely normal. What it means is that deploying without a snapshot first could have quietly reverted some of it. From here I'll keep a running record of what's live, so you'll always be able to see what changed and we can roll back to any day."

You've now converted "your store is a mess" into "I've de-risked something you didn't know was risky," and you've established that a rollback exists — which is what a merchant actually cares about.

How ThemeSync tracks live themes

Live and draft themes can be tracked, not just development themes. A production theme pulls from the store on an interval and commits what changed, so drift becomes history instead of a surprise.
The store is treated as the source of truth in that direction. Automatic sync only ever pulls and records. Deploying git back to a live theme is always a deliberate action.
Deploys pull first. The deploy flow captures last-second store changes before uploading, so a merchant edit made minutes earlier isn't wiped by your release.
Untracked live themes get flagged. The store's theme list is checked against what's being tracked, so a live theme nobody has a copy of is surfaced rather than assumed away.
Sync state is visible per store. Whether tracking is healthy, stale or erroring is something you can see across a portfolio, instead of finding out during a deploy.

Takeaways

Your repo is not the source of truth for a live theme. The store is.
Merchants, apps and other developers all write to the live theme, and none of it reaches your branch.
theme push overwrites. On a live theme that means silently reverting whatever drifted.
Measure drift before you quote and before you deploy — pull the live theme and diff it. Ten minutes.
Adopt the store's current state as an honest baseline commit. Don't tidy it first.
Pull automatically, push manually. Pulling records; pushing destroys.
Frame the finding to the client as risk removed, and give them a rollback story.

Know what’s live before you deploy over it

ThemeSync tracks live and draft themes into git on a schedule, flags live themes nobody is watching, and pulls before every deploy so merchant edits survive your release.

Try ThemeSync Free →