The very first port of call when onboarding to any ecommerce business using Shopify should be to ask the single question: how do you back-up your theme code?
And if the answer isn't git, you've now got your first task!
Below is the end-to-end workflow I now use to manage our Shopify theme versioning via the Shopify Github Integration.
Shopify CLI
Other than the obvious like git, you'll want to make sure you also have Shopify CLI installed so you can get started with shopify theme pull
Branches
Unlike most software development which generally has a single release candidate, ecommerce stores often go through different themes correlating to campaigns or product releases. For this reason, I don't use the main branch as our live theme but rather the most up-to-date stable version of the core theme.
Instead, I opt for the following branching strategy:
-
development- current development branch -
review- "Review Only" theme synced to Shopify for other team-mates to review main-
live-theme- current live theme in Shopify
Note that these branches are not necessarily persistent (except for main) but are usually like live-theme-campaign-X.
This allows asynchronous development and marketing reviews without impacting our current live theme, as well as the ability to prepare for future theme changes like sale events. By ensuring that the currently published theme is connected to a branch, we retain the ability to push any urgent updates or bug fixes while still allowing any direct edits to be made in Shopify.
Pull Requests
Pull requests are always made to the main branch, documenting the primary line of changes & updates. Updates to a live theme are still first merged to main, and then main merged into the live-theme.
Tagging
An optional step which we implement is creating tags to label key releases, usually the accumulation of many PR merges to main at the point where it becomes a new live theme at the beginning of a campaign. For this we have another branch bau which we merge to from main via a PR, and a Github action that auto-creates the tag. The main point of this is more for historical tracking of themes mapped to campaigns, but is a great way to mark available backup points.
This is the process that works for my small team where it is primarily me working on the theme with some input from other colleagues. A good balance of maintaining git best practise without overcomplicating for the scale we need.
Top comments (0)