Skip to content
Shopify Theme Handbook

GitHub Workflow

TL;DR: Solis’s real branch-to-PR-to-merge loop, the pre-PR routine, and what CI checks automatically.

Branch naming and commit conventions are covered earlier, in Branching & Commits under Getting Started, since you need them before you make your first commit. This section picks up from there: pull requests, review, and CI. Shopify also offers a separate, optional GitHub integration that can connect a branch directly to a theme, with changes syncing both ways; that feature is covered in Branching & Commits rather than assumed here, since it’s not confirmed as something Solis currently relies on.

What’s on this page group

Section titled “What’s on this page group”
  • Pull Requests & Review: the pre-PR routine, the PR template, merging, and the checklist for reviewing AI-generated code.
  • CI Automation: what checks run automatically every time you push code. This automatic checking is called CI, short for continuous integration.

The full loop, end to end

Section titled “The full loop, end to end”

Here’s how a single Solis change actually moves from your machine to a merged PR. Think of it as a loop, because it repeats every time you make a change.

  1. Branch off an up-to-date main, and build locally with shopify theme dev (see Branching & Commits).
  2. Before you push: run /sol-shopify-review on whatever you built or changed by hand, then /code-review on the full diff (skip this if /figma-to-feature already ran it for you), then shopify theme check for zero errors. See Pull Requests & Review.
  3. Pull the latest main into your branch, and resolve any conflicts locally before opening the PR.
  4. Open a PR against main. GitHub auto-fills the description from the PR template; delete sections or checklist items that don’t apply, rather than leaving them unchecked.
  5. CI runs Prettier and theme-check automatically (see CI Automation). It does not run /sol-shopify-review or /code-review for you, those are on you, before you push.
  6. A teammate reviews your code. They also open the live preview link and try it out for themselves.
  7. Merge with “Merge pull request” (a plain merge commit, never a rebase), and delete the branch.

Do / Don’t

Section titled “Do / Don’t”
✅ Do❌ Don’t
Run /sol-shopify-review and /code-review yourself before every PR. Neither runs automatically.Assuming CI’s Prettier/theme-check run covers code review. It doesn’t check this theme’s conventions or general code quality, only formatting and theme-check rules.
Pull main into your branch before opening the PR, every time, not just when you expect conflicts.Only discovering a merge conflict after opening the PR, and resolving it blind in GitHub’s conflict editor instead of locally with your editor and the full theme running.
Keep your feature branches short-lived.Letting feature branches go stale for weeks. The eventual PR becomes one big, hard-to-review change instead of several small, easy ones.
Use “Merge pull request” and delete the branch afterward.Rebasing a merged PR’s commits. Rebasing rewrites commit SHAs, which breaks anyone else’s copy of the branch.

Further reading

Section titled “Further reading”