Lovable が GitHub に接続された後に安全に開発する方法: ブランチ、同期の競合、ロールバックとデプロイメントのチェック

米国の Google トレンドでは、「愛らしい雰囲気のコーディングによる収益」が上昇中のクエリとして表示されます。

プロジェクトが長期的に維持できるかどうかを実際に決定するのは、ページの最初のバージョンが生成される速度ではなく、信頼できる信頼できる情報源になった後の GitHub のコラボレーション方法です。

GitHub アプリをインストールするときにリポジトリのスコープを狭める

Only select repositories が優先されます。

個々のアカウントと組織全体のすべてのリポジトリを承認しないでください。

既存の実稼働倉庫への接続を避けるために、実験プロジェクト用に新しい倉庫を作成します。

インストール後に GitHub のアプリケーション設定で権限を確認してください。

設置者、認可された組織、倉庫、日付を記録します。

初めて接続する前にクリーンなベースラインを保存します

1
2
3
4


git clone https://github.com/example/lovable-demo.git
cd lovable-demo
git status --short
git log -1 --oneline

ローカルコピーは、同期の問題をトラブルシューティングするための独立した証拠です。

接続直後に Lovable によって作成された最初のコミットを観察します。

作成者、ファイル数、ロックファイル、環境変数の例を確認してください。

True .env はコミットに入るべきではありません。

まず、デフォルトのブランチを変更できる人を決定します

デフォルトのブランチの保護を有効にします。

プルリクエスト、ステータスチェック、および少なくとも 1 つのレビューが必要です。

ビルドプロセスを容易にするためだけに強制プッシュを許可しないでください。

Lovable への変更は機能ブランチに入力され、PR を通じてマージされます。

地元の開発者も同じルールに従います。

同期競合の根本原因は通常、双方向の同時編集です。

Lovable とローカル IDE が同じコンポーネントを同時に変更すると、競合が避けられません。

Lovable セッションを開始する前に、最新のリモート送信を同期してください。

関連ファイルはセッション中に占有されているとみなされます。

完了したらすぐに提出し、他の開発者に通知してください。

レビューできない 1 つの大きなコミットに数十のビルドを蓄積しないでください。

競合の処理はコードのセマンティクスに依存します

1
2
3


git fetch origin
git diff origin/main...HEAD
git diff --check

ロックファイルの競合がある場合は、両側のテキストを手動で結合しないでください。

正しい依存関係宣言を選択した後、パッケージマネージャーのビルドを再実行します。

コンポーネントが競合する場合、ページはローカルで実行する必要があり、エージェントは単に「両側を維持」を選択することはできません。

環境変数は名前と説明のみを送信します

.env.example には以下を含めることができます:

1
2
3


VITE_API_URL=https://api.example.test
SUPABASE_URL=https://project.supabase.co
SUPABASE_ANON_KEY=replace-me

サービスロールキー、データベースパスワード、または支払いプラットフォームキーを入力しないでください。

ブラウザ側の変数が Secret と呼ばれる場合でも、フロントエンドパッケージに入力される可能性があります。

オンラインにする前にビルド製品を検索します。

1

rg -n "service_role|sk_live_|BEGIN PRIVATE KEY" dist

各世代後にレビューされるのは 4 種類の高リスク変更のみです

まず認証と権限について見てみましょう。

データベースの移行をもう一度見てみましょう。

次に、外部 API と支払いを見てみましょう。

最後に、削除操作と上書き操作を見てみましょう。

スタイルの調整はすぐに確認できますが、ファイル数によって安全境界をサンプリングすることはできません。

最小 CI しきい値を確立する

1
2
3
4
5


npm ci
npm run lint
npm run typecheck
npm test
npm run build

コマンドはプロジェクトの実際のスクリプトに依存します。

ビルドツールがテストを削除すると、CI はテスト数の変化を表示する必要があります。

ビルドが成功しても、ログインと支払いのプロセスが正しいことを意味するわけではありません。

少なくとも 1 つのエンドツーエンドのスモークテストを追加します。

追跡可能なバージョンを使用して公開する

各製品リリースは Git コミットに対応します。

デプロイメントプラットフォーム上のコミット SHA を記録します。

1
2
3


git rev-parse HEAD
git tag deploy-2026-07-27-01
git push origin deploy-2026-07-27-01

タグは単なるアンカーポイントであり、ブランチ保護に代わるものではありません。

ロールバックは「AI に変更を元に戻す」ではありません

まず、展開プラットフォーム上で以前に成功したビルドに切り替えます。

次に、Git revert を使用してクリアなリバースコミットを生成します。

1

git revert <bad-commit>

データベースが移行されている場合、フロントエンドのロールバックでは不十分な場合があります。

移行では、前方修正パスまたは互換性パスを事前に準備する必要があります。

破壊的な移行を自動的に元に戻せるとは考えないでください。

統合切断時の終了

すべての Lovable 変更がプッシュされていることを確認します。

必要なプロジェクトの説明をエクスポートします。

GitHub 上のアプリのウェアハウス権限を取り消します。

プロジェクトに公開されたら、サードパーティのキーをローテーションします。

CI と展開が Lovable の一時的な ID に依存していないことを確認します。

発売前チェックリスト

GitHub アプリは指定されたリポジトリにのみアクセスします。
デフォルトのブランチでは直接プッシュが禁止されています。
各世代は、レビュー可能な小さな提出物に対応します。
.env とプロダクションキーは Git にありません。
CI には、lint、タイプ、テスト、ビルドが含まれます。
認証、支払い、データ許可は手動で検証されます。
デプロイメントをコミット SHA にマッピングできます。
フロントエンドとデータベースのロールバックがリハーサルされました。

GitHub が監査可能な履歴を保存すると、Lovable は 1 回限りのプロトタイピングツールから管理可能な開発エントリポイントに変わります。

GitHub 統合ドキュメント

GitHub アプリでできることをチェックしてください

組織設定の GitHub アプリページで Lovable インストールの詳細を開き、リポジトリのアクセス許可と組織のアクセス許可をそれぞれ記録します。コンテンツ、プルリクエスト、アクション、シークレット、管理に焦点を当てます。

現在のワークフローでコードの同期のみが必要な場合は、トラブルを避けるために組織管理権限を付与しないでください。権限昇格には新たなビジネス上の正当な理由が必要であり、倉庫管理者によって確認される必要があります。

認可された倉庫は四半期ごとに検査されます。アーカイブされたプロジェクト、一時的なデモ倉庫、引き渡された顧客倉庫は適時に削除する必要があります。

CODEOWNERS を使用して機密ディレクトリを保護する

.github/CODEOWNERS にレビューの責任者を指定します。

1
2
3
4


/supabase/migrations/  @example/database-team
/.github/workflows/    @example/platform-team
/src/auth/             @example/security-team
/src/payments/         @example/payments-team

次に、ブランチ保護ルールでコード所有者の承認を有効にします。ファイルのみが存在し、ルールが有効になっていない場合、GitHub は責任者の承認を強制的に待機しません。

生成ツールは、通常のページを変更するときにも迅速にマージできます。認証、移行、展開の構成に関しては、より厳格なレビューパスが自動的に入力されます。

Lovable セッションを 1 つの PR に制限する

セッションが開始される前に、タスク番号を持つブランチを作成します。

1

git switch -c lovable/issue-142-profile-form

このラウンドのビルドのみを許可すると、問題 142 が解決されます。他の問題が見つかった場合は、それらを新しい問題に書き込み、同じブランチにない場合は修正します。

ユーザーに表示される変更と検証コマンドを説明する情報をコミットします。スクリーンショットは PR の説明に添付されますが、スクリーンショットでは電子メール、アクセストークン、顧客データが隠されている必要があります。

同期前後のファイルリストを比較

1
2


git diff --name-status origin/main...HEAD
git diff --numstat origin/main...HEAD

ボタンを変更したが、ルーティング、認証、または多数の依存関係が変更された場合は、まず同期を一時停止してください。再スキャフォールディング、ロックファイルのグローバルな書き換え、または誤ったベースブランチの選択が発生していないか確認してください。

大きな変更は必ずしも悪意のあるものではありませんが、小さな UI PR と混ぜるべきではありません。

GitHub アクション最小限の権限を使用する

ワークフローの開始時に権限を明示的に宣言します。

1
2


permissions:
  contents: read

検査結果の公表が必要な場合のみchecks: writeを増やしてください。 PR ビルドには contents: write は必要なく、すべての環境シークレットへのアクセスも必要ありません。

フォークからの PR は、運用資格情報を使用してワークフローを実行しません。サードパーティのアクションはコミット SHA に固定され、Dependabot または手動プロセスを介して更新されます。

プレビュー環境は実稼働環境から分離されています

各 PR はプレビュー URL を作成できますが、接続できるのはテストデータベースとテスト支払いアカウントのみです。ビジネス担当者が実際のデータを誤って記録することを防ぐために、明らかな非実稼働マークがページに表示されます。

プレビューは有効期限が切れると自動的に破棄されます。破棄アクションでは、共有テストデータベース内の他のブランチデータは削除されませんが、ブランチ ID によって独自のテナントまたはスキーマがクリーンアップされます。

データベース移行のマージシーケンス

まずプレビューデータベースに移行を適用し、互換性テストを実行してから、アプリケーションコードをマージします。実稼働デプロイメントでは、前方互換性のある 2 フェーズの変更が採用されます。

たとえば、新しいフィールドを追加するときは、まず古いコードがそれを無視できるようにします。新しいコードが安定するまで待ってから、より厳しい制約を追加してください。フィールドを削除するには、まず読み取りを停止し、移行する前にリリースサイクルを観察します。

GitHub 監査ログを使用して異常な同期を追跡する

組織アカウントは、監査ログからアプリのインストール、権限の変更、ウェアハウスへのアクセスをクエリできます。不明な送信が発生した場合、または多数のウェアハウスが承認された場合は、まずアプリを一時停止し、ログの証拠を保存します。

異常なブランチをすぐに削除しないでください。コミット、作成者、時刻、GitHub 配信 ID を保存すると、ユーザーのアクション、自動同期、資格情報の悪用を区別できます。

実際のロールバックドリル

プレビュービルドを選択し、意図的に視覚的なエラーがあるものの、データは破壊されないコミットをデプロイします。現在の SHA を記録し、前のバージョンに戻します。

CDN キャッシュ、フロントエンドリソース、API バージョンがすべて復元されていることを確認します。ローカルキャッシュを正常なロールバックと誤認しないように、ブラウザを強制的に更新した後、再度確認してください。

次に git revert を実行して、デフォルトのブランチ履歴にもこのロールバックを反映させます。デプロイメントプラットフォームのロールバックとソースコードのロールバックは不可欠です。

プロジェクト引き継ぎ時のチェックリスト

プロジェクトが他のチームに引き渡された後、ウェアハウス管理者、デプロイメントプラットフォーム、ドメイン名、Supabase、および支払いアカウントの所有権が譲渡されます。 Lovable App は、受信者が管理するリポジトリに対して再認証します。

ビルドキーとデプロイメントキーをローテーションし、古いチームメンバーのセッションを閉じます。最後に、新しいアカウントからクローン、ビルド、展開が完了し、プロジェクトが元の開発者のコンピューターに依存していないことが証明されます。