開発フロー設計
案件の種類に応じて安全な開発フロー（環境・テーマ・Git）を設計できる
最終確認: 2026-09
解説
受託の現場でなぜ必要か： この回では、案件の種類に応じて安全な開発フロー（環境・テーマ・Gitの扱い）を設計できるようになります。
受託では、公開テーマに直接pushして営業中のストアが崩れる事故は、フローを決めていないことから起きます。
新規構築ではどこに作るか
クライアントに渡す前提なら、Dev Dashboardで「クライアント譲渡用ストア（client transfer store）」として作って作り込みます。
完成後にDev Dashboardから譲渡すると、クライアントがメールで承諾し、プランを選びます。
テスト用のDev store（開発ストア）は譲渡できません。
既存のストアに作るなら、非公開テーマとしてpushします。
既存改修では複製に対して作業する
公開テーマを複製し、複製に対してtheme devとpushを行います。
プレビューURLで確認してもらい、承認後に公開します。
公開テーマへ直接pushしません。
営業中のストアに、未確認の変更が即座に出てしまうからです。
Gitはどう運用するか
テーマはGitで管理し、GitHub連携で「本番テーマ＝mainブランチ」「検証テーマ＝develop」のように結び付けます。
テーマエディタでの変更は、コミットとしてブランチに戻ります（約10秒以内の変更は1コミットにまとまります）。
切断したブランチは再接続できません（新しいテーマになります）。
発展：衝突の扱いとテーマの名前
クライアントがテーマエディタで触ったsettings_data.jsonやJSONテンプレートと、開発側の変更がぶつかることがあります。
テンプレートと設定ファイルの扱いをルール化します（.shopifyignoreでpushから除外するなど）。
テーマ名には、日付・ブランチ・目的を入れます（例: 2026-09-15 feature/hero）。
テーマライブラリの上限にも注意します。
※ ShopifyはShopify Inc.の商標です。本サイトは個人が制作した非公式の学習教材であり、同社の承認・提携・後援を受けていません。記載内容は2026-09時点のものです。料金・上限値・管理画面のラベルは変わるため、作業の前に公式ドキュメントで確認してください。