Shopify theme version control: what agencies actually use

29 July 2026 · 7 min read

Shopify theme version control is a problem every agency solves twice: once properly for the themes they build, and again badly for the client stores they inherit, where merchants edit the live theme and nobody knows what the code looked like last month.

There are four workable approaches. They are not alternatives so much as layers, and the mistake is assuming the first one covers the store.

1. Git, with the theme developed locally

The theme lives in a repository, developers work locally with shopify theme dev, and deployment is shopify theme push. Everything Git gives you — branches, blame, review, history — applies.

The gap is who else touches the store. The moment a merchant edits a section in the theme editor or an app writes a snippet, the live theme diverges from the repository and Git no longer describes reality. It records what your team intended, not what is running.

2. Shopify's GitHub integration

Shopify can connect a GitHub branch to a theme and sync in both directions, so changes made in the theme editor are committed back to the branch. That closes most of the divergence gap for connected themes, and for teams already on GitHub it is the natural default.

The limits worth planning around: it applies per theme, so anything not connected is unprotected; deleting a theme does not undo the deletion; and non-technical stakeholders will not be reading commits when the live store breaks at 9pm.

3. Scheduled `shopify theme pull`

A cron job that pulls each theme into a dated folder or a commit. Cheap, transparent, and it captures the live state including whatever merchants and apps did.

It is also one more piece of infrastructure to own: credentials that expire, a machine that must be up, and a failure mode where nobody notices the job stopped until the day the backup is needed. Whoever builds it should also build an alert for it not running.

4. Automatic capture inside the store

Capture triggered by store events rather than by a schedule or a person: a full copy when a theme is published, and another before anything writes to a theme. It covers merchant edits and app changes by construction, because it runs where they happen.

This is what Auto Theme Sync does — every file captured, stored content-addressed by SHA-256 so repeated captures of a barely-changed theme cost almost nothing, with a file-level diff between any two themes.

What none of them cover by default

Whichever option you pick, three gaps stay open unless you close them deliberately:

1. Theme deletion. Removing a theme in the admin is immediate, and a repository connected to that theme does not undo it.
2. Settings drift. Merchants change colours, section order and content through the theme editor far more often than anyone changes code — and those changes live in files most people never look at.
3. Who is watching. Every scheduled or automatic mechanism eventually fails quietly. If nobody would notice a week of missing captures, you do not have version control, you have a cron job.

Choosing for a client store you did not build

For an inherited store the ranking is different from a greenfield build, because you do not control who edits what:

1. Get automatic capture in place first — it covers the people you do not manage.
2. Add the GitHub integration for the theme your team actively develops.
3. Keep a labelled duplicate before any large piece of work.
4. Agree in writing that nobody edits the live theme, and give them a staging theme so the rule is followable.

Whatever you choose, test a restore before you need one. A backup nobody has ever restored from is a belief, not a backup.

Related: does Shopify back up your theme? · a safe staging-to-live workflow

Keep reading

Shopify staging theme: a workflow that does not lose work
How to run a Shopify staging theme properly — where to make changes, how to move them live, and how to avoid the drift that makes staging useless.

How to update a Shopify theme without losing customizations
A theme update can overwrite months of custom code. Here is the order of operations that keeps your changes, and what to check the moment the update lands.