How can I use one Github branch for multiple identical Shopify stores?

[MatthewG]

Hi,

I am using Shopify Online Store 2.0 with Github integration. I am wanting to use one master branch that will be used across multiple stores. All the stores will be identical with small changes being made with liquid conditions.

This all works fine apart from the theme settings config files. I want a unique settings_data.json file for each site as the sites will have different content, but with the same codebase. When I make a change in the theme settings it then pushes this change to Github which then updates the theme settings for all the other sites.

What is the best approach for dealing with this? Does anyone have a workflow strategy that they can share that solves this issue?

Any ideas?

Thanks,

Matt

[Jhenricks518]

Also currently looking for a good workflow for this. 

as an agency, we want to have one GitHub repo with our “main” default theme and have custom configurations of that theme be used across many client builds. When we add new features to our main repo, it would be great if all the clients using that theme could get the updates. 

right now we’ve got it setup as a “template” repo and we start new repos per client. Hard to keep the client sites up to date as we implement new base features though. 

[RossellaF]

I am also looking for a good workflow for this.

I am thinking about having different branches the live themes on each store, connected to the same Github repository, so that the changes through the theme customizer are being kept track of.

The problem presents itself when wanting to work on a specific feature: which branch do I create the feature from (what is the real source of truth)?

Thinking it might be easier just to have a different repository for each store, even though it increases the time to manage any change to the code

[MatthewG · Accepted solution]

@RossellaF The solution I ended up coming up with is having all our Stores connect to the same repository.

Our branching strategy is having a different live branch for each site that will serve as the live theme.

For my specific use case, the majority of the code would be identical apart from the custom content being loaded on them via the Customiser (apart from a few small changes). So my solution was creating a Github workflow. We create the branch, complete the development work, then push to the Release branch. I setup a Github Workflow to exclude the settings_data.json and settings_schema.json files. Then on push to the release branch it runs a bunch of git commands (not the cleanest) to checkout each of the live branches for each site and push all the changes excluding the settings files to all of our Live themes at the same time. This doesn't overwrite the customiser settings.

Saying this, there are a couple of liquid conditions for unique code for Tracking and other small bits, but other than that this solution worked the best for me. Definitely improvements can be made though! 

[RossellaF]

I see. So technically you don't have the Github integration set up, but you replicate that functionality with Github workflow instead. What happens if you need to create a new custom section? Do you add the code from the Shopify code editor directly?

[MatthewG]

We are using the Github integration for our live themes. Each live theme has it's own Github branch (live/store-name). We do the development work on another branch and push to a branch called "Release". The Github workflow triggers when something is pushed to the "Release" branch. From there, that workflow pushes all the code changes excluding the setting files to all the other "live/store-name" branches. As we have the Github Integration set up, it then updates all the code on Shopify (without overwriting the settings files!). 

Hope this helps.

[RossellaF]

That's really clever, thanks for sharing this with me! 

[Wbarber]

Hey Matthew,

That sounds like a great set up. Is there any chance you could share your Github workflows yml code? It would be a great help. Cheers

[MatthewG]

Hi,

See the public repo with the workflow yml code: https://github.com/matthewgelder/DawnTest

Note that this hasn't actually being used in production yet as it's experimental and can be heavily optimised I'm sure!

Thanks,

Matt

[lpscleay]

Struggling with this solution. I'm pretty novice with GitHub so please correct me if I'm wrong with any of this:

GitHub: main pushing theme files to several live branches using a workflow with paths-ignore excluding config and templates directories.

The issue (I think!), is that a directory (e.g. templates) specified in a GitHub workflow with paths-ignore references the directory of the changed files, not the destination directory. So a file changed outside of 'templates' will trigger the workflow, but one changed inside 'templates' will not. But when the workflow IS triggered, it updates all directories including 'templates'. So for me this workflow hasn't solved the issue of preventing the JSON settings files in the live branches from being overwritten.

I really hope I'm 100% wrong and have set something up incorrectly — please let me know if so!...

[Danh11]

You're right. I've gone down this road to try to make it work but ran into the same issue with this method that you described.

[manuelpineda]

have you found a solution for this?

[lpscleay]

Nope. No solution. Right now, I'm having to maintain separate repos for each storefront, which is a PITA...

[Danh11]

I did end up with a pretty good solution which has been working so far. It takes a bit of setup and uses github actions. This is just a rundown of what it involves..

Create a main repository, along with another repository for each storefront.

Each repository will start out identical to one another.

Each repository will have 5 branches: master, production, staging, preliminary-production, preliminary-staging.

The main repository has a github action that triggers on push to either staging or production branches.
The workflow contains a job for each child theme and runs one after another.

The workflow described in each job is roughly as follows:

1. An environment/container is created with rsync and git installed and configured.

2. A source directory is created containing all files of the repository (the main repository which is running this action).

3. A destination directory is created by cloning the child theme repository that this current job relates to.

4. The branch of the destination directory will then need to be switched to the preliminary branch that you are pushing to (ie. preliminary-production).

4. Rsync is used to sync the files from /source to /destination. The important part here is to exclude the directories of 'config' and 'templates' as these are specific to the storefront theme configuration.

5. The changes that are now present in the preliminary branch of /destination now get committed, merged, and pushed.

6. The preliminary branch is then merged into the main branch (ie. preliminary-production to production) and pushed.

7. Check the action logs in github to make sure it was successful and there were no merge conflicts.

In the event of merge conflicts, manually fix them in your editor. This shouldn't happen unless code is changed outside of this workflow and you end up with merge issues.

Basically, you're only ever making changes to the main repository. The rest is handled by the action workflow.

[BenjaminAntoni]

I have had all the struggles outlined in this entire thread. Could you share a repo with your solution? It would be lovely to be able to dig into and understand.

[Danh11]

I'd love to but I can't as it's a client's website and technically the IP of the agency I work for. But I see you got there in the end 🙂

[BenjaminAntoni]

FOUND A SOLUTION!

I've been down this rabbit hole disappointed, but finally I found a solution in a custom GitHub action built exactly for this:
https://github.com/Jamiemccleave/shopify-multi-store-deployer

[lpscleay]

It seems that this workflow specifically includes the theme .json files in the merge? (or I may be reading it wrong? I'm not super familiar with gitworkflows) — my issue is that .json files need to be excluded to maintain any individual site settings... 

[Danh11]

I haven't dug into the action in that repo, but you're right, you want to exclude the json files in the config directory. I outlined this in one of my previous replies. 

[BenjaminAntoni]

No no. It specifically excludes all the settings files, even to the level where it leaves in the settings_schema so you can publish new changes to the schema to all live stores.
It is literally made exactly for this scenario.

[lpscleay]

Brilliant. It's working for you then? — I'll be looking deeper asap...

[BenjaminAntoni]

We've just begun using it. So far it works flawlessly.

It will require some hands on action when installing a new app, to avoid conflicts (if app injects code, it will come from the theme to github affecting non-setting files, and you're heading towards a conflict). But for code changes coming from your editor, and avoiding changing or conflicting with the settings pushed to github from the live theme, it works smooth.

[lpscleay]

As an aside, I was planning to try another idea using github submodules (https://github.blog/2016-02-01-working-with-submodules/😞
— main repo contains theme files as usual.
— live repos linked to shopify are not branches of main, but pull submodules from main for the assets, layout, sections, and snippets directories only.
— templates, locales and config in live repo are normal directories and updated by the shopify admin as usual.

I think this submodule setup would have the same app conflict issue you described above (git commands on submodule directories are ignored so shopify should not be able to alter anything in them).

I'm not sure if this would be a wise or practical (or even functional — can you pull a directory as a submodule, or only the entire repo?) method, but perhaps another possibility...

[lpscleay]

So I'm revisiting this just now, and struggling to get this straight. Might just be too early on a Monday! The action has a from_branch parameter and a single to_branch parameter — which seems to work as expected for main > live_A, but I'm not sure what the action setup should be for multiple branches? e.g.
main — live_A
          — live_B
          — live_C

[Rasmus_Larsen]

Hi Matthew,

Might be worth while looking at this one? - https://apps.shopify.com/themeflow