Ветки – Коммит и откат
Версионируйте репозитории как код. Коммит замораживает форк в неизменяемый образ; ветка даёт ему имя; checkout превращает любой коммит обратно в свежий редактируемый форк. В этом уроке мы фиксируем известное рабочее состояние, удаляем настоящую таблицу PostgreSQL, и получаем все строки обратно за секунды.
Смотреть урок
Модель
Коммиты никогда не меняются – они даже монтироваться отказываются. Форки никогда не ждут – checkout это почти мгновенный reflink-клон. Полная ментальная модель описана в руководстве по веткам.
Создайте контрольную точку
Маркерный файл делает версию видимой, а настоящая база данных делает откат осмысленным: таблица customers содержит три строки.
rdc term connect --machine <machine-name> --repository app:work --command 'echo v1 > version.txt && cat version.txt'Запишите первую версию состояния в рабочий fork.
rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'В этом fork также работает настоящая база данных PostgreSQL: таблица customers содержит три строки.
rdc repo commit --name app:work --message 'v1 baseline' --machine <machine-name>Выполните commit рабочего fork: полное состояние repository, включая базу данных, заморожено в неизменяемый именованный снимок.
rdc repo branch --branch stable --name app:workСоздайте branch, указывающую на commit: понятное имя для замороженного состояния.
Коммит фиксирует всё: файлы и директорию данных PostgreSQL. Ветка stable теперь именует это замороженное состояние.
Продолжайте работу
rdc term connect --machine <machine-name> --repository app:work --command 'echo v2 > version.txt && cat version.txt'Продолжайте работать: fork меняется, зафиксированная история остаётся замороженной.
Катастрофа
Рискованное изменение удаляет таблицу. Затем запрос подтверждает, что ущерб реален.
rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "DROP TABLE customers"'Опасное изменение удаляет таблицу customers в рабочем fork.
rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'Запрос к таблице теперь завершается ошибкой: relation "customers" does not exist. Данные действительно исчезли из рабочего fork.
ERROR: relation "customers" does not exist. Три строки – пропали. В реальной жизни это тот момент, когда холодеет в животе; здесь это завязка для развязки.
rdc repo commit --name app:work --message 'v2 risky change' --machine <machine-name>Зафиксируйте и новое состояние, включая удалённую таблицу; история растёт как git log.
rdc repo log --name app:work --machine <machine-name>Просматривайте историю commit через repo log: сообщения, авторы, родители.
История записывает то, что произошло на самом деле, включая сломанное состояние: v2 risky change сверху, v1 baseline под ним.
Откат за секунды
rdc repo checkout --ref stable --from app:work --tag rollback --machine <machine-name>Переключите ветку stable в свежий записываемый fork: почти мгновенно благодаря copy-on-write.
rdc repo up --name app:rollback --machine <machine-name>Поднимите rollback fork, он работает параллельно с рабочим fork.
rdc term connect --machine <machine-name> --repository app:rollback --command 'cat version.txt'Прочитайте файл-маркер в rollback fork: первая версия, именно такая, какой была зафиксирована.
rdc term connect --machine <machine-name> --repository app:rollback --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'Запросите таблицу customers в rollback fork: три строки, именно такие, какими были зафиксированы. Rollback восстановил базу данных, а не только файлы.
Форк с откатом читает v1, и таблица customers возвращается со всеми тремя строками. Откат восстановил базу данных, а не только файлы. Ничего не перезаписано: рабочий форк по-прежнему содержит версию два, и видео открывает оба в VS Code как доказательство.
Далее: Живая миграция.