リポジトリをフォークする

これが作業の進め方を変える機能です。本番環境全体（アプリ、データベース、設定ファイル）を数秒でクローンできます。サイズ制限なし、追加ディスク不要、何度でもフォークできます。

キャッチフレーズ: 本番をクローンして、何も壊さない。

チュートリアル動画

失うものを用意する

まず、フォークの分離を証明するためにファイルを追加します。VS Code でリポジトリを開き、リポジトリ内でマーカーファイルを作成します。

rdc vscode connect -m my-server -r my-app

CLIリファレンス： rdc vscode connect

echo "Hello from production" > index.html

では、フォークしましょう。

フォーク

rdc repo fork --parent my-app -m <machine-name> --tag experiment --up

1つのコマンドで repo 全体（アプリ、データベース、設定ファイル）をクローンします。Fork の所要時間は、repo のサイズが 1GB、100GB、1TB であっても一定です。

親から独立したクローンへ展開

コマンド1つです。すべて（アプリ、データベース、設定ファイル）を数秒でクローンしました。もう一度実行すれば、また別の独立したクローンが作成されます。

なぜこんなに速いのか

フォルダサイズに関係なく、リンクの共有速度は同じ

フォルダのリンクを共有することを想像してください。フォルダが小さくても大きくても、リンクは同じです。フォルダは重くても、リンクは軽いのです。

1 GB、100 GB、1 TB。常に同じ時間。

フォークも同じ仕組みです。1 GB、100 GB、1 TB。常に同じ時間がかかります。

共有されるものと、自分のもの

多くの鏡と1つの太陽: 共有ベース、変更は自分のもの

親リポジトリを固定されたソースだと考えてください。フォークはそのコピーオンライトビューです。フォークに書き込むと、その書き込みはフォーク内に留まります。何個のフォークが向いていても、親は動きません。

太陽は持てないけれど、鏡の中に持てる。

親がその後変わったら？

フォークは凍った写真、親は流れ続ける川

スナップショットを思い浮かべてください。フォークするとき、その瞬間に親を凍らせます。親は動き続けますが、フォークは動きません。

親リポジトリがその後変わっても、あなたのフォークはフォークした時点のまま残ります。

川は持てないけれど、写真の中に持てる。

ディスク使用量は増えない

100 GB リポジトリの5つのフォーク、合計はまだ約 100 GB

だからディスクが溢れないのです。100 GB のリポジトリを5つフォークしても、合計はまだ約 100 GB です。各フォークで変更した分だけディスクが使われます。

何度でもフォークしてください。ディスクは気づきもしません。

フォークが引き継がないもの: シークレット

フォークが意図的に引き継がないものが1つあります。シークレットです。フォークは API キー、データベースパスワード、Stripe トークンを持たない状態で起動します。だからこそ「本番をクローンして、何も壊さない」が実際に機能するのです。サンドボックスは本物の顧客に課金できません。なぜなら、あなたのふりをすることができないからです。この仕組みはシークレットの管理チュートリアルで適切にセットアップします。

分離を確認する

両方のリポジトリを並べて確認します。

rdc repo list -m <machine-name>

両方の repo が同一マシン・同一ディスク上に、完全に独立した2つの環境として共存しています。

my-app と my-app:experiment が同時に動いているのが確認できます。元のリポジトリでは、マーカーファイルがそのままの場所にあります。

rdc term connect -m <machine-name> --repository my-app --command 'ls -la index.html'

元の repo を確認して分離を検証します。マーカーファイルはそのまま残っています。fork を作成しても親は変更されません。

では、フォーク内だけで破壊的な変更を加えてみましょう。

rdc term connect -m <machine-name> --repository my-app:experiment --command 'rm index.html && echo removed'

fork の内部にあるマーカーファイルのみ削除します。これは fork に限定された破壊的な変更です。

元のリポジトリに戻って確認します。

rdc term connect -m <machine-name> --repository my-app --command 'ls -la index.html'

元の repo に戻します。マーカーファイルはそのまま残っています。親と fork は同じイメージを共有しますが、別々の Docker daemon と別々のファイルシステムで動作します。

マーカーファイルはここにあり、手つかずのままです。フォークの変更はフォーク内に留まりました。同じイメージ、別の Docker デーモン、別のファイルシステムです。

クリーンアップ

作業が終わったら、フォークを削除するだけです。

rdc repo delete --name my-app:experiment -m <machine-name>

作業が完了したら fork を削除します。元の repo には影響がなく、安全に fork、実験、破棄のワークフローを実行できます。

元のリポジトリはまったく変わりません。フォークして、実験して、壊して、削除する。 リスクゼロです。

次: フォーク分離の実際