Saltar al contenido principal Saltar a navegación Saltar al pie de página
Tiempo limitado: Programa Design Partner. Plan BUSINESS gratis de por vida.

Branching: Commit y rollback

Congela estados de repositorio en commits inmutables, dales nombre con branches y recupera cualquier commit como un fork nuevo con escritura.

Branching: Commit y rollback

Versiona tus repositorios igual que el código. Un commit congela un fork en una imagen inmutable; un branch le pone nombre; checkout convierte cualquier commit en un fork nuevo con escritura. En este tutorial hacemos commit de un estado conocido como bueno, borramos una tabla real de PostgreSQL y recuperamos todas las filas en segundos.

Ver el tutorial

El modelo

Commits, branches, checkout

Los commits nunca cambian: ni siquiera se pueden montar. Los forks nunca esperan: el checkout es un clon reflink casi instantáneo. El modelo completo está en la guía de branching.

Crea un checkpoint

Un archivo marcador hace visible la versión, y una base de datos real hace que el rollback sea significativo: la tabla customers tiene tres filas.

rdc term connect --machine <machine-name> --repository app:work --command 'echo v1 > version.txt && cat version.txt'

Escribe la versión uno de tu estado en el fork de trabajo.

rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'

El fork también ejecuta una base de datos PostgreSQL real: la tabla customers tiene tres filas.

rdc repo commit --name app:work --message 'v1 baseline' --machine <machine-name>

Haz commit del fork de trabajo: el estado completo del repositorio, base de datos incluida, queda congelado en una instantánea inmutable con nombre.

rdc repo branch --branch stable --name app:work

Crea una rama que apunte al commit, un nombre legible para el estado congelado.

El commit captura todo: archivos y el directorio de datos de PostgreSQL. El branch stable ahora nombra ese estado congelado.

Sigue trabajando

rdc term connect --machine <machine-name> --repository app:work --command 'echo v2 > version.txt && cat version.txt'

Continúa trabajando: el fork cambia, el historial de commits permanece congelado.

El desastre

Un cambio arriesgado borra la tabla. Luego la consulta confirma que el daño es real.

rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "DROP TABLE customers"'

El cambio arriesgado elimina la tabla customers en el fork de trabajo.

rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'

Consultar la tabla ahora falla: la relación "customers" no existe. Los datos realmente desaparecieron del fork de trabajo.

ERROR: relation "customers" does not exist. Tres filas, desaparecidas. En la vida real este es el momento en que se te cae el alma a los pies; aquí es la preparación para el remate.

rdc repo commit --name app:work --message 'v2 risky change' --machine <machine-name>

Haz commit del nuevo estado también, tabla eliminada incluida; el historial crece como un git log.

rdc repo log --name app:work --machine <machine-name>

Recorre el historial de commits con repo log, mensajes, autores y padres.

El historial registra lo que ocurrió de verdad, estado roto incluido: v2 risky change arriba, v1 baseline debajo.

Rollback en segundos

rdc repo checkout --ref stable --from app:work --tag rollback --machine <machine-name>

Haz checkout de la rama stable a un fork escribible nuevo, casi instantáneo gracias a copy-on-write.

rdc repo up --name app:rollback --machine <machine-name>

Levanta el fork de rollback, se ejecuta junto al fork de trabajo.

rdc term connect --machine <machine-name> --repository app:rollback --command 'cat version.txt'

Lee el archivo marcador en el fork de rollback: versión uno, exactamente como se hizo el commit.

rdc term connect --machine <machine-name> --repository app:rollback --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'

Consulta la tabla customers en el fork de rollback: tres filas, exactamente como se hizo el commit. El rollback restauró la base de datos, no solo los archivos.

El fork del rollback lee v1, y la tabla customers vuelve con las tres filas. El rollback restauró la base de datos, no solo los archivos. No se sobreescribió nada: el fork de trabajo sigue teniendo la versión dos, y el vídeo abre ambos en VS Code para demostrarlo.


Siguiente: Migración en vivo.