Branching: Commit e Rollback
Versione os seus repositórios como código. Um commit congela um fork numa imagem imutável; um branch dá-lhe nome; o checkout transforma qualquer commit num novo fork gravável. Neste tutorial fazemos commit de um estado estável, apagamos uma tabela PostgreSQL real e recuperamos todas as linhas em segundos.
Ver o tutorial
O modelo
Os commits nunca mudam: recusam-se mesmo a montar. Os forks nunca esperam: o checkout é um clone reflink quase instantâneo. O modelo mental completo está no guia de branching.
Fazer um checkpoint
Um ficheiro de marcador torna a versão visível, e uma base de dados real torna o rollback significativo: a tabela customers tem três linhas.
rdc term connect --machine <machine-name> --repository app:work --command 'echo v1 > version.txt && cat version.txt'Escreva a versão um do seu estado na fork de trabalho.
rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'A fork também executa um banco de dados PostgreSQL real: a tabela customers tem três linhas.
rdc repo commit --name app:work --message 'v1 baseline' --machine <machine-name>Faça o commit da fork de trabalho: o estado completo do repositório, banco de dados incluído, é congelado em um snapshot imutável e nomeado.
rdc repo branch --branch stable --name app:workCrie uma branch apontando para o commit, um nome legível para o estado congelado.
O commit captura tudo: ficheiros e o diretório de dados do PostgreSQL. O branch stable dá agora nome a esse estado congelado.
Continuar a trabalhar
rdc term connect --machine <machine-name> --repository app:work --command 'echo v2 > version.txt && cat version.txt'Continue trabalhando: a fork muda, o histórico commitado permanece congelado.
O desastre
Uma alteração arriscada apaga a tabela. A query confirma que o dano é real.
rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "DROP TABLE customers"'A mudança arriscada remove a tabela customers na fork de trabalho.
rdc term connect --machine <machine-name> --repository app:work --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'Consultar a tabela agora falha: a relação "customers" não existe. Os dados realmente sumiram da fork de trabalho.
ERROR: relation "customers" does not exist. Três linhas, desaparecidas. Na vida real este é o momento em que o estômago cai; aqui é a preparação para a resolução.
rdc repo commit --name app:work --message 'v2 risky change' --machine <machine-name>Faça o commit do novo estado também, tabela removida incluída; o histórico cresce como um git log.
rdc repo log --name app:work --machine <machine-name>Percorra o histórico de commits com repo log, mensagens, autores, pais.
O histórico regista o que realmente aconteceu, estado quebrado incluído: v2 risky change em cima, v1 baseline abaixo.
Fazer rollback em segundos
rdc repo checkout --ref stable --from app:work --tag rollback --machine <machine-name>Faça o checkout da branch stable em uma fork nova e editável, quase instantâneo graças ao copy-on-write.
rdc repo up --name app:rollback --machine <machine-name>Suba a fork de rollback, ela roda junto com a fork de trabalho.
rdc term connect --machine <machine-name> --repository app:rollback --command 'cat version.txt'Leia o arquivo marcador na fork de rollback: versão um, exatamente como foi commitado.
rdc term connect --machine <machine-name> --repository app:rollback --command 'docker exec db psql -U app -d app -c "SELECT count(*) FROM customers"'Consulte a tabela customers na fork de rollback: três linhas, exatamente como foram commitadas. O rollback restaurou o banco de dados, não apenas os arquivos.
O fork do rollback lê a v1, e a tabela customers voltou com as três linhas. O rollback restaurou a base de dados, não apenas os ficheiros. Nada foi sobrescrito: o fork de trabalho ainda tem a versão dois, e o vídeo abre ambos no VS Code para o provar.
Próximo: Migração em Direto.