Branching : Commit & Rollback

Versionnez vos dépôts comme du code. Un commit fige un fork en une image immuable ; une branche le nomme ; checkout retransforme n’importe quel commit en un nouveau fork inscriptible. Dans ce tutoriel, nous committons un état connu comme stable, supprimons une vraie table PostgreSQL, et récupérons toutes les lignes en quelques secondes.

Regarder le tutoriel

Le modèle

Commits, branches, checkout

Les commits ne changent jamais : ils refusent même de se monter. Les forks n’attendent jamais : le checkout est un clone reflink quasi-instantané. Le modèle mental complet se trouve dans le guide du branching.

Créer un point de contrôle

Un fichier marqueur rend la version visible, et une vraie base de données rend le rollback concret : la table customers contient trois lignes.

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

Écrivez la version un de votre état dans le fork de travail.

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

Le fork fait aussi tourner une vraie base de données PostgreSQL : la table customers contient trois lignes.

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

Commitez le fork de travail : l'état complet du repository, base de données comprise, est figé dans un snapshot immuable et nommé.

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

Créez une branche pointant vers le commit, un nom lisible pour l'état figé.

Le commit capture tout : les fichiers et le répertoire de données PostgreSQL. La branche stable nomme désormais cet état figé.

Continuer à travailler

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

Continuez à travailler : le fork évolue, l'historique commité reste figé.

Le désastre

Un changement risqué supprime la table. Puis la requête confirme que les dégâts sont réels.

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

La modification risquée supprime la table customers dans le fork de travail.

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

Interroger la table échoue maintenant : la relation "customers" n'existe pas. Les données ont vraiment disparu du fork de travail.

ERROR: relation "customers" does not exist. Trois lignes, disparues. En production, c’est le moment où le sol se dérobe ; ici, c’est la mise en place du dénouement.

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

Commitez aussi le nouvel état, table supprimée comprise ; l'historique s'allonge comme un git log.

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

Parcourez l'historique des commits avec repo log : messages, auteurs, parents.

L’historique enregistre ce qui s’est vraiment passé, état cassé inclus : v2 risky change au-dessus, v1 baseline en dessous.

Revenir en arrière en quelques secondes

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

Extrayez la branche stable dans un nouveau fork inscriptible, quasi-instantané grâce au copy-on-write.

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

Lancez le fork de rollback, il tourne en parallèle du fork de travail.

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

Lisez le fichier marqueur dans le fork de rollback : version un, exactement tel que commité.

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

Interrogez la table customers dans le fork de rollback : trois lignes, exactement telles que commitées. Le rollback a restauré la base de données, pas seulement les fichiers.

Le fork de rollback lit v1, et la table customers est de retour avec ses trois lignes. Le rollback a restauré la base de données, pas seulement les fichiers. Rien n’a été écrasé : le fork de travail conserve toujours la version deux, et la vidéo ouvre les deux dans VS Code pour le prouver.

Suivant : Migration en direct.