Ein Repository forken

Forken Sie eine gesamte Produktionsumgebung (die App, die Datenbank, die Konfigurationsdateien) in Sekunden. Beliebige Größe. Null zusätzlicher Speicher. Forken Sie beliebig oft.

Der Leitspruch: Produktion klonen, nichts kaputt machen.

Tutorial ansehen

Etwas zum Verlieren einrichten

Geben Sie der laufenden App zunächst eine Datei, damit Sie die Isolation des Forks beweisen können. Öffnen Sie das Repo in VS Code, dann erstellen Sie im Repo eine Markierungsdatei:

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

CLI-Referenz: rdc vscode connect

echo "Hello from production" > index.html

Jetzt forken.

Forken

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

Ein einziger Befehl klont das gesamte Repo: App, Datenbank und Konfigurationsdateien. Die Fork-Zeit ist konstant, unabhängig von der Repo-Größe, ob ein Gigabyte, hundert Gigabyte oder ein Terabyte.

Der Parent verzweigt sich in unabhängige Klone

Ein Befehl. Alles wurde geklont (die App, die Datenbank, die Konfigurationsdateien), und es dauerte Sekunden. Führen Sie es erneut aus und Sie erhalten einen weiteren unabhängigen Klon.

Warum ist es so schnell?

Das Teilen eines Ordner-Links ist gleich schnell, unabhängig von der Größe des Ordners

Der Grund sind btrfs Reflinks. Ein Fork erstellt einen neuen Dateisystem-Baum, der auf dieselben Datenblocke wie der Parent zeigt. Beim Forken werden keine Daten kopiert. Es handelt sich nur um Metadaten, daher spielt die Größe des Parent keine Rolle für die Dauer des Forkens.

1 GB, 100 GB, 1 TB. Immer die gleiche Zeit.

Forken funktioniert genauso. 1 GB, 100 GB, 1 TB. Immer die gleiche Zeit.

Was geteilt wird, was Ihnen gehört

Viele Spiegel, eine Sonne: gemeinsame Basis, Ihre Änderungen gehören Ihnen

Stellen Sie sich das Parent-Repo als feste Quelle vor. Ihr Fork ist eine Copy-on-Write-Sicht darauf. Schreiben Sie in den Fork, bleiben die Schreibvorgänge im Fork. Der Parent bewegt sich nicht, egal wie viele Forks auf ihn zeigen.

Sie können die Sonne nicht festhalten, aber Sie können sie in einem Spiegel halten.

Was, wenn der Parent sich später ändert?

Ein Fork ist ein eingefrorenes Foto; der Parent fließt weiter wie ein Fluss

Denken Sie jetzt an einen Snapshot. Wenn Sie forken, frieren Sie den Parent in diesem genauen Moment ein. Der Parent läuft weiter. Ihr Fork nicht.

Wenn sich das Parent-Repo später ändert, bleibt Ihr Fork dort, wo er war.

Sie können einen Fluss nicht festhalten, aber Sie können ihn in einem Foto festhalten.

Speichernutzung bleibt konstant

Fünf Forks eines 100-GB-Repos, insgesamt immer noch etwa 100 GB

Deshalb läuft Ihr Speicher nicht voll. Fünf Forks eines 100-GB-Repos? Insgesamt immer noch etwa 100 GB. Sie zahlen nur Speicher für das, was Sie in jedem Fork ändern.

Forken Sie fünfmal, wenn Sie möchten. Ihr Speicher wird es kaum bemerken.

Was Forks nicht erben: Secrets

Es gibt eine Sache, der der Fork bewusst nicht folgt: Secrets. Ein Fork startet ohne API-Schlüssel, ohne Datenbankpasswörter, ohne Stripe-Tokens. Deshalb funktioniert “Produktion klonen, nichts kaputt machen” wirklich. Ihre Sandbox kann keine echten Kunden belasten, weil sie nicht so tun kann, als wären Sie es. Das richten wir ordentlich im Tutorial Secrets verwalten ein.

Isolation verifizieren

Beide Repos nebeneinander auflisten:

rdc repo list -m <machine-name>

Beide Repos koexistieren nun auf derselben Maschine und Festplatte als zwei vollständig unabhängige Umgebungen.

Sie sehen my-app und my-app:experiment, die gleichzeitig laufen. Im Original-Repo ist die Markierungsdatei genau dort, wo Sie sie gelassen haben:

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

Überprüfe die Isolation, indem du das originale Repo inspizierst: Die Markierungsdatei bleibt an ihrem Platz. Das Erstellen eines Fork verändert das übergeordnete Repo nicht.

Jetzt eine destruktive Änderung vornehmen, aber nur im Fork:

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

Lösche die Markierungsdatei nur innerhalb des Fork. Dies ist eine destruktive Änderung, die auf den Fork beschränkt ist.

Zurück zum Original wechseln und prüfen:

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

Wechsle zurück zum originalen Repo: Die Markierungsdatei bleibt intakt. Das übergeordnete Repo und der Fork teilen dasselbe Image, laufen jedoch auf separaten Docker-Daemons und separaten Dateisystemen.

Die Markierungsdatei ist noch hier, unberührt. Die Änderungen des Forks blieben im Fork. Gleiche Images, getrennte Docker-Daemons, getrennte Dateisysteme.

Aufräumen

Wenn Sie fertig sind, löschen Sie einfach den Fork:

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

Lösche den Fork, wenn du fertig bist. Das originale Repo bleibt unberührt, was einen sicheren Fork-, Experiment- und Verwerfen-Workflow ermöglicht.

Das Original bleibt genau so, wie es war. Forken, experimentieren, Dinge kaputtmachen, löschen. Kein Risiko.

Weiter: Fork-Isolation in der Praxis.