Git と NeonDB のブランチ
Git のブランチと Neon の DB ブランチを1対1で対応させる。永続の幹は残し、PR ごとの使い捨ては GitHub 連携で自動生成・自動削除
Neon の DB ブランチは差分だけのコピーで、何 GB あっても一瞬で作れます。Git のブランチと名前をそろえて 1 対 1 で対応させるのが運用の型です。
- ブランチは『永続の幹』と『PR ごとの使い捨て』の 2 系統
- 使い捨ては PR の開閉に連動して CI が自動処理
- スキーマの正本は Git のマイグレーション
なぜ Git と Neon でブランチをそろえるのか
Git のブランチは開発の日常になりました。では、同じ気軽さでデータベースまで分岐できたら、開発は何が変わるのでしょうか。幹と枝の役割分担を、1 本の木からたどりましょう。
各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
構成図「Git のブランチ と Neon のブランチを 1対1 で対応させる」。ブロック5個、つながり4本。 【ブロック】 - main: Git: main ／ Neon: production - staging: Git: staging ／ Neon: staging - dev/alice: 開発者 alice 専用 - dev/bob: 開発者 bob 専用 - preview/pr-123: PR #123 専用・使い捨て 【流れ】 - 永続の幹（消さない）: main → staging - 開発者ブランチ（準永続）: main → staging → dev/alice - 使い捨て（PRごと）: main → preview/pr-123
PRごとに『作ってはすぐ壊す』流れ（GitHub 連携）
各ステップ・参加者・分岐をクリックすると、その仕組みの説明がここに表示されます。
この図をテキストで読む
シーケンス図「PRごとに作って、用が済んだら壊す（GitHub 連携）」。参加者4人、ステップ10個。 【参加者】（左から右） - 開発者: PRを出す人 - GitHub: リポジトリ / PR - CI: GitHub Actions - Neon: DBブランチ基盤 【流れ】（上から下へ） ── ① PRを開く → 使い捨てDBを自動で作る ── 1. 開発者 → GitHub: feature ブランチを push、PRを作成 2. GitHub → CI: PR open イベントで CI を起動 3. CI → Neon: preview/pr-123 を作成（本番のコピー） 4. Neon → CI: 接続URLを返す（即時）（応答） 5. CI（自身で処理）: マイグレーション適用＋テスト＋プレビュー 6. CI → GitHub: プレビューURLをPRにコメント（応答） ── ② PRをマージ／クローズ → 使い捨てDBを自動で壊す ── 7. 開発者 → GitHub: PRをマージ（または close） 8. GitHub → CI: merged / closed イベント 9. CI → Neon: preview/pr-123 を削除 10. Neon → CI: 片付け完了（待機ぶんは scale to zero）（応答）
永続ブランチ と 使い捨てブランチ を見くらべる（早見表）
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。2列 × 8行。 【列】 1. 永続ブランチ（ずっと残す） 2. 使い捨てブランチ（PRの間だけ） 【比較】（観点ごとに） ■ 寿命 - 永続ブランチ: ずっと（消さない） - 使い捨てブランチ: PRの間だけ ■ 例 - 永続ブランチ: main / staging / dev/alice - 使い捨てブランチ: preview/pr-123 ■ 数 - 永続ブランチ: 少数 / 環境＋人数ぶん - 使い捨てブランチ: PRの数だけ増減 ■ Gitとの対応 - 永続ブランチ: 長命ブランチに対応 / main / staging - 使い捨てブランチ: feature / PR と1対1 ■ 名前合わせ - 永続ブランチ: ゆるくてよい / 手動・少数 - 使い捨てブランチ: 厳密に合わせる / CIが機械照合 ■ 作成・削除 - 永続ブランチ: 手動・たまに - 使い捨てブランチ: CIが自動で作成＆削除 ■ 鮮度の保ち方 - 永続ブランチ: 定期リフレッシュが必要 / 再生成 / reset from parent - 使い捨てブランチ: 常に新鮮 / 毎回作り直す ■ コスト - 永続ブランチ: 常時ぶん（ただし安い） / 待機は scale to zero - 使い捨てブランチ: PR中だけ・差分課金 【観点】 - 永続を見る: 永続ブランチ - 使い捨てを見る: 使い捨てブランチ
『永続』も定期的に捨てる
常設の dev ブランチを不変だと思わないのが勘どころです。作るのも消すのも一瞬なので、週次などで作り直すと本番相当の新鮮なデータで開発でき、『手元では動くのに本番で壊れる』を避けられます。
押さえておきたい用語
- コピーオンライト
- 複製時に実体を丸ごとコピーせず、変更した部分だけを記録する方式。何 GB あってもブランチ作成が一瞬で済む。
- 使い捨てブランチ（ephemeral）
- PR の間だけ存在し、閉じると消すブランチ。preview/pr-123 など、Git の feature ブランチと1対1で対応する。
- プレビュー環境
- PR ごとに使い捨て DB ブランチを立て、本番のコピーで変更を検証する仕組み。GitHub Actions などで自動化する。
- reset from parent
- ブランチを削除せず、親ブランチの最新状態へ中身を巻き戻す Neon の操作。常設ブランチの鮮度を保つのに使う。
- scale to zero
- 使っていないブランチのコンピュートを自動停止する仕組み。待機中のブランチの費用がほぼ0になる。
- マイグレーション
- テーブル定義の変更を記録・適用する仕組み。Drizzle ではファイルとして Git 管理し、スキーマ変更の正本になる。
ここから先へ
この解説とつながりのあるページ