Fork de un repositorio

Haz fork de un entorno de producción completo (la app, la base de datos, los archivos de configuración) en segundos. Cualquier tamaño. Cero disco extra. Haz fork tantas veces como quieras.

El lema: clona producción, no rompas nada.

Ver el tutorial

Prepara algo que perder

Primero, dale al repo en ejecución un archivo para probar el aislamiento del fork. Abre el repo en VS Code, luego dentro del repo crea un archivo marcador:

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

Referencia CLI: rdc vscode connect

echo "Hello from production" > index.html

Ahora haz el fork.

Fork

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

Un solo comando clona el repo completo: app, base de datos y archivos de configuración. El tiempo de fork es constante sin importar el tamaño del repo, ya sea un gigabyte, cien gigabytes o un terabyte.

El repo padre se ramifica en clones independientes

Un comando. Clonó todo (la app, la base de datos, los archivos de configuración) y ocurrió en segundos. Ejecútalo de nuevo y obtendrás otro clon independiente.

¿Por qué es tan rápido?

Compartir un enlace de carpeta tiene la misma velocidad sin importar el tamaño de la carpeta

La razón es los reflinks de btrfs. Un fork crea un nuevo árbol del sistema de archivos que apunta a los mismos bloques de datos que el padre. No se copian datos en el momento del fork. Todo es metadatos, por lo que el tamaño del padre nunca influye en cuánto tiempo tarda el fork.

1 GB, 100 GB, 1 TB. El mismo tiempo, siempre.

El fork funciona igual. 1 GB, 100 GB, 1 TB. El mismo tiempo, siempre.

Qué se comparte y qué es tuyo

Muchos espejos, un sol: base compartida, tus cambios son tuyos

Piensa en el repo padre como una fuente fija. Tu fork es una vista de copia en escritura sobre él. Escribe en el fork y los cambios se quedan en el fork. El padre no se mueve, sin importar cuántos forks apunten a él.

No puedes sostener el sol, pero puedes sostenerlo en un espejo.

¿Qué pasa si el padre cambia después?

Un fork es una fotografía congelada; el padre sigue fluyendo como un río

Ahora piensa en una instantánea. Cuando haces fork, congelas el padre en ese momento exacto. El padre sigue avanzando. Tu fork no.

Si el repo padre cambia después, tu fork se queda donde estaba.

No puedes sostener un río, pero puedes sostenerlo en una foto.

El uso del disco se mantiene plano

Cinco forks de un repo de 100 GB siguen siendo unos 100 GB en total

Por eso tu disco no explota. ¿Cinco forks de un repo de 100 GB? Siguen siendo unos 100 GB en total. Solo pagas disco por lo que cambias en cada fork.

Haz fork cinco veces si quieres. Tu disco ni lo notará.

Lo que los forks no heredan: los secrets

Hay una cosa que el fork deliberadamente no hereda: los secrets. Un fork comienza sin claves de API, sin contraseñas de base de datos, sin tokens de Stripe. Por eso “clona producción, no rompas nada” realmente funciona. Tu sandbox no puede cobrar a clientes reales porque no puede hacerse pasar por ti. Lo configuramos correctamente en el tutorial de Gestión de Secrets.

Verificar el aislamiento

Lista ambos repos uno al lado del otro:

rdc repo list -m <machine-name>

Ambos repos ahora coexisten en la misma máquina y disco como dos entornos completamente independientes.

Verás my-app y my-app:experiment ejecutándose al mismo tiempo. En el original, el archivo marcador está exactamente donde lo dejaste:

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

Verifica el aislamiento inspeccionando el repo original: el archivo marcador permanece en su lugar. Crear un fork no modifica el padre.

Ahora haz un cambio destructivo, pero solo dentro del fork:

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

Elimina el archivo marcador solo dentro del fork. Este es un cambio destructivo limitado al fork.

Vuelve al original y comprueba:

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

Vuelve al repo original: el archivo marcador permanece intacto. El padre y el fork comparten la misma imagen pero se ejecutan en Docker daemons separados y sistemas de archivos separados.

El archivo marcador sigue aquí, intacto. Los cambios del fork se quedaron en el fork. Mismas imágenes, Docker daemons separados, sistemas de archivos separados.

Limpieza

Cuando termines, simplemente elimina el fork:

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

Elimina el fork cuando termines. El repo original no se ve afectado, lo que permite un flujo de trabajo seguro de fork, experimentación y descarte.

El original queda exactamente como estaba. Fork, experimenta, rompe cosas, elimina. Sin riesgo.

Siguiente: Aislamiento del fork en acción.