Branching: Commit & Rollback
Versionieren Sie Ihre Repositories wie Code. Ein Commit friert einen Fork in ein unveränderliches Image ein; ein Branch benennt es; Checkout verwandelt jeden Commit zurück in einen frischen, beschreibbaren Fork. In diesem Tutorial speichern wir einen bekannt guten Zustand, löschen eine echte PostgreSQL-Tabelle und haben alle Zeilen in Sekunden zurück.
Tutorial ansehen
Das Modell
Commits ändern sich nie - sie verweigern sogar das Einhängen. Forks warten nie - Checkout ist ein nahezu sofortiger Reflink-Klon. Das vollständige Konzept finden Sie im Branching-Leitfaden.
Einen Checkpoint setzen
Eine Markierungsdatei macht die Version sichtbar, und eine echte Datenbank macht den Rollback bedeutsam: Die Tabelle customers enthält drei Zeilen.
rdc term connect --machine <machine-name> --repository app:work --command 'echo v1 > version.txt && cat version.txt'Schreib Version eins deines Zustands in den Working-Fork.
rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'Der Fork betreibt außerdem eine echte PostgreSQL-Datenbank: Die Tabelle customers enthält drei Zeilen.
rdc repo commit --name app:work --message 'v1 baseline' --machine <machine-name>Committe den Working-Fork: Der vollständige repository-Zustand, einschließlich der Datenbank, wird in einem unveränderlichen, benannten Snapshot eingefroren.
rdc repo branch --branch stable --name app:workErstelle einen Branch, der auf den Commit zeigt, einen lesbaren Namen für den eingefrorenen Zustand.
Der Commit erfasst alles: Dateien und das PostgreSQL-Datenverzeichnis. Der Branch stable benennt jetzt diesen eingefrorenen Zustand.
Weiterarbeiten
rdc term connect --machine <machine-name> --repository app:work --command 'echo v2 > version.txt && cat version.txt'Weiterarbeiten: Der Fork ändert sich, die committete History bleibt eingefroren.
Katastrophe
Eine riskante Änderung löscht die Tabelle. Dann bestätigt die Abfrage, dass der Schaden real ist.
rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "DROP TABLE customers"'Die riskante Änderung löscht die Tabelle customers im Working-Fork.
rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'Die Abfrage der Tabelle schlägt jetzt fehl: Relation "customers" existiert nicht. Die Daten sind wirklich aus dem Working-Fork verschwunden.
ERROR: relation "customers" does not exist. Drei Zeilen, weg. Im echten Leben ist das der Moment, in dem einem der Magen sinkt; hier ist es die Vorbereitung für die Auflösung.
rdc repo commit --name app:work --message 'v2 risky change' --machine <machine-name>Committe auch den neuen Zustand, gelöschte Tabelle inklusive. Die History wächst wie ein git log.
rdc repo log --name app:work --machine <machine-name>Durchsuche die Commit-History mit repo log: Nachrichten, Autoren, Parents.
Die Historie zeichnet auf, was wirklich passiert ist, kaputten Zustand eingeschlossen: v2 risky change oben, v1 baseline darunter.
In Sekunden zurückrollen
rdc repo checkout --ref stable --from app:work --tag rollback --machine <machine-name>Check den stable Branch in einen frischen, beschreibbaren Fork aus, nahezu sofort dank copy-on-write.
rdc repo up --name app:rollback --machine <machine-name>Starte den Rollback-Fork. Er läuft parallel zum Working-Fork.
rdc term connect --machine <machine-name> --repository app:rollback --command 'cat version.txt'Lies die Markierungsdatei im Rollback-Fork: Version eins, genau wie committed.
rdc term connect --machine <machine-name> --repository app:rollback --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'Frage die Tabelle customers im Rollback-Fork ab: drei Zeilen, genau wie committed. Das Rollback hat die Datenbank wiederhergestellt, nicht nur die Dateien.
Der Rollback-Fork liest v1, und die Tabelle customers ist mit allen drei Zeilen wieder da. Der Rollback hat die Datenbank wiederhergestellt, nicht nur Dateien. Nichts wurde überschrieben: Der Arbeits-Fork enthält weiterhin Version zwei, und das Video öffnet beide in VS Code zum Beweis.
Weiter: Live-Migration.