> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # キットが改善されたらコピーを更新する ソースリポジトリの改善を自分のコピーに取り込む — 開始地点を記録し、新しいリビジョンを取得し、ブランチでマージし、デプロイ前に検証します。 ## 1. 開始地点を記録する 更新は貼り付けではなく小さなプロジェクトとして扱います：持っているキットのリビジョンと新しいものを比較し、変更を移し、デプロイ前にブランチでテストします。これは、プロジェクトがキットリポジトリのフォーク（GitHub がソースとの接続を保つコピー）であっても、自分のアプリにコピーしたコードであっても機能します。 何よりも先に、プロジェクトに 3 つのことをメモしてください：開始したキットのコミット（SHA — 正確な 1 つのバージョンを識別する Git の短いコード）、受け取ったリポジトリ（supastack-web、supastack-mobile、supastack-desktop、または All Platforms モノレポ）、そしてすでに自分で加えた変更です。 キットリポジトリとモノレポは異なる履歴を持つため、一方のブランチを他方のフォークにマージしてはいけません。開始 SHA を記録していなかった場合は、フォークでは git merge-base で最も近い共通バージョンを見つけ、選択的導入では最後にコピーしたファイルとテストを特定してください — 正確なベースラインが不確かなときは、より広い差分を確認します。 ## 2. 新しいリビジョンを取得してマージする 以下のコマンドは、作業を保存してコミットした状態（クリーンな作業ツリー）で、プロジェクトフォルダー内のターミナルで実行します — 中途半端なものがマージに混ざらないようにするためです。山括弧の中の言葉は置き換え用テンプレートです： 全体を自分の値で置き換えます。表示されている GitHub アドレスはプレースホルダーです。フォークしたリポジトリのアドレスを使ってください。 各行の動作：git remote add はコピーに kit-upstream（キットリポジトリ）という 2 番目のアドレスを教え、git fetch はファイルに触れずに最新の状態をダウンロードします。git switch -c は別の更新ブランチを作成し、確認中もメインブランチがそのまま保たれます。git log は取り込もうとしているコミットを列挙し、git diff --stat はどのファイルが変わったかを要約します。コミットのタイトルだけでなく、使っているモジュールの完全な差分を読んでください。git merge が新しいコードを更新ブランチに取り込みます。 Git が kit-upstream リモートがすでに存在すると報告した場合は、remote add の行をスキップして git fetch で続行します。 は手順 1 で記録した開始 SHA です。 ``` # Upstream is the platform repository you forked — substitute its real URL # (supastack-web shown; use supastack-mobile or supastack-desktop as fits). git remote add kit-upstream https://github.com//supastack-web.git git fetch kit-upstream git switch -c upgrade/kit-update git log --oneline ..kit-upstream/main git diff --stat ..kit-upstream/main git merge kit-upstream/main ``` ## 3. 作業を失わずに競合を解決する 競合とは両側が同じ行を変更したことを意味します：キットが進み、あなたも同じ場所をカスタマイズしました。Git はマージを一時停止してファイルに印を付けます — 損傷を報告しているのではなく、選択を求めているのです。 印の付いた各ファイルをエディターで開き、行ごとに判断します：製品独自のテキスト、名前、設定は残し、キットの修正と構造的な変更は取り込みます。カスタマイズしたファイルをキットの新しいバージョン全体で置き換えて競合を解決してはいけません — それは作業を消します。更新ブランチ内で解決し、続行前に解決した各領域のテストを実行してください。 マージがうまくいかなければ、git merge --abort がブランチをマージ前の状態に戻します。自分で更新ブランチをマージするまで、この流れの何もメインブランチやデプロイを変更しません。 ## 4. データの更新とデプロイを正しい順序で行う 新しいキットのリビジョンはデータベースを変更することがあります。packages/db/drizzle/（マイグレーションフォルダー）の新しいファイルを読み、マイグレーションを適用する前に本番データをバックアップしてください。まず使い捨てのコピーでテストします。互換性のあるスキーマ変更は、それを必要とするコードの前にデプロイします：マイグレーションがデータを削除または再形成する場合、アプリコードだけをロールバックしても古いスキーマは復元できません。 新しい .env.example と自分の設定を比較し、新たに必要になった値をホスティングダッシュボードに追加します。.env ファイルはシークレットを含み、Git にコミットされることはありません — 各マシンとデプロイで手動で再作成し、NEXT_PUBLIC_ と EXPO_PUBLIC_ の値には入れません。 デプロイ前に、キット自体の検証ゲートを実行します。All Platforms モノレポでは、corepack pnpm check:local が有料資格情報なしで lint、型チェック、ユニットテスト、フォーマットチェックを実行し、corepack pnpm verify:local が本番ビルドとブラウザテストスイートを追加します。単一サーフェスのフォークでは、そのリポジトリ自身のテストとビルドコマンドを実行します。その後、ステージングでのスモーク確認を行います：サインインし、2 つ目のワークスペースを試し、製品の主要なユーザージャーニーを実行します。 すべてが通過したら、受け入れた対象 SHA と解決した競合を書き留めます — そのメモが次回更新の開始ベースラインになります。 ``` corepack pnpm check:local # fuller gate: adds the production build and browser suites corepack pnpm verify:local ``` ## 5. フォークではなく一部をコピーした場合 選択的導入（既存アプリへのキットモジュールのコピー）はキットと Git 履歴を共有しないため、git merge は助けになりません。代わりに古いソース SHA と対象のソース SHA を比較し、導入した部分に触れる変更だけを移植します。 モジュールの公開型、永続化スキーマとマイグレーション、サーバー呼び出し元、設定、テスト、ドキュメントを 1 つの単位として確認します — パッケージ内の変更は他の場所での対応するルートや環境の変更を必要とする場合があり、単一のヘルパーをコピーすると残りが古いコントラクトのままになることがあります。どのキットファイルを取り、どれをスキップし、何を変えたかという短い適応メモを残してください — 次の更新であなたの選択を再現できます。 更新で実行中のコピーの何かが壊れた場合は、自分の変更を元に戻す前にトラブルシューティングガイドに取り組んでください。 [更新後の問題を修正する](https://supastack.dev/ja/docs/web/troubleshooting.md) ## 次へ [モジュール概要](https://supastack.dev/ja/docs/modules.md)