Fare il Fork di un Repository

Fai il fork di un intero ambiente di produzione (l’app, il database, i file di configurazione) in pochi secondi. Qualsiasi dimensione. Zero disco aggiuntivo. Puoi fare il fork tutte le volte che vuoi.

Il motto: clona la produzione, non rompere nulla.

Guarda il tutorial

Crea qualcosa da perdere

Prima, dai all’app in esecuzione un file per dimostrare l’isolamento del fork. Apri il repo in VS Code, poi all’interno del repo crea un file marcatore:

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

Riferimento CLI: rdc vscode connect

echo "Hello from production" > index.html

Ora fai il fork.

Fork

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

Un singolo comando clona l'intero repo: app, database e file di configurazione. Il tempo di fork è costante indipendentemente dalla dimensione del repo, che sia un gigabyte, cento gigabyte o un terabyte.

Il parent si divide in cloni indipendenti

Un solo comando. Ha clonato tutto, l’app, il database, i file di configurazione, ed è successo in pochi secondi. Eseguilo di nuovo e ottieni un altro clone indipendente.

Perché è così veloce?

Condividere un link a una cartella ha la stessa velocità indipendentemente dalla dimensione della cartella

Il motivo sono i btrfs reflinks. Un fork crea un nuovo albero del filesystem che punta agli stessi blocchi di dati del parent. Nessun dato viene copiato al momento del fork. È tutto metadata, quindi la dimensione del parent non influisce mai sul tempo impiegato dal fork.

1 GB, 100 GB, 1 TB: stesso tempo, ogni volta

Il fork funziona allo stesso modo. 1 GB, 100 GB, 1 TB: stesso tempo, ogni volta.

Cosa è condiviso, cosa è tuo

Molti specchi, un sole: base condivisa, le tue modifiche sono tue

Pensa al repo parent come a una sorgente fissa. Il tuo fork è una vista copy-on-write di essa. Scrivi nel fork e le scritture rimangono nel fork. Il parent non si muove, indipendentemente da quanti fork vi puntino.

Non puoi tenere il sole, ma puoi tenerlo in uno specchio.

E se il parent cambia dopo?

Un fork è una fotografia congelata; il parent continua a scorrere come un fiume

Ora pensa a uno snapshot. Quando fai il fork, congeli il parent in quell’esatto momento. Il parent continua a muoversi. Il tuo fork no.

Se il repo parent cambia dopo, il tuo fork rimane dov’era.

Non puoi tenere un fiume, ma puoi tenerlo in una foto.

L’utilizzo del disco rimane stabile

Cinque fork di un repo da 100 GB: ancora circa 100 GB in totale

Ecco perché il tuo disco non esplode. Cinque fork di un repo da 100 GB? Ancora circa 100 GB in totale. Paghi disco solo per ciò che cambi in ogni fork.

Fai il fork cinque volte se vuoi: il tuo disco non se ne accorgerà nemmeno.

Cosa i fork non ereditano: i segreti

C’è una cosa che il fork deliberatamente non segue: i segreti. Un fork inizia senza chiavi API, senza password del database, senza token Stripe. Ecco perché “clona la produzione, non rompere nulla” funziona davvero: la tua sandbox non può addebitare ai clienti reali perché non può fingersi te. Configuriamo questo correttamente nel tutorial Gestione dei Segreti.

Verifica l’isolamento

Elenca entrambi i repo affiancati:

rdc repo list -m <machine-name>

Entrambi i repo coesistono ora sulla stessa macchina e sullo stesso disco come due ambienti completamente indipendenti.

Vedrai my-app e my-app:experiment in esecuzione contemporaneamente. Nell’originale, il file marcatore è esattamente dove l’hai lasciato:

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

Verifica l'isolamento ispezionando il repo originale: il file marker è ancora al suo posto. La creazione di un fork non modifica il parent.

Ora fai una modifica distruttiva, ma solo all’interno del fork:

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

Elimina il file marker solo all'interno del fork. Si tratta di una modifica distruttiva limitata al fork.

Torna all’originale e controlla:

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

Torna al repo originale: il file marker è ancora intatto. Il parent e il fork condividono la stessa immagine ma girano su Docker daemon separati e filesystem separati.

Il file marcatore è ancora qui, intatto. Le modifiche del fork sono rimaste nel fork. Stesse immagini, daemon Docker separati, filesystem separati.

Pulizia

Quando hai finito, elimina semplicemente il fork:

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

Elimina il fork al termine. Il repo originale non viene modificato, consentendo un flusso di lavoro sicuro di fork, sperimentazione ed eliminazione.

L’originale rimane esattamente com’era. Fork, sperimenta, rompi cose, elimina. Nessun rischio.

Successivo: L’Isolamento del Fork in Azione.