Um dia eu estava usando o Git (ainda estou usando) e a eletricidade diminuiu enquanto eu estava cometendo.
Quando eu (na verdade, a eletricidade) voltou, o repositório Git estava corrompido. Não lembro o nome exato, mas era algo como "referências inválidas" ou algo parecido.
É fácil adivinhar que a confirmação foi interrompida no meio da operação (eu estava confirmando através do IntelliJ, que faz as adições de índice automaticamente). Também foi fácil adivinhar que, na verdade, 'commit' não é tão ACID quanto a operação DBMS com o mesmo nome.
P : Existe uma maneira de garantir que as operações de alteração de reposição respeitem a atomicidade? ou seja, se a eletricidade diminuir novamente e eu estiver comprometendo, gostaria que meu sistema de arquivos não estivesse corrompido.
Respostas:
Não sei se existe uma maneira de fazer com que o Git commit sobreviva a falhas de energia perfeitamente cronometradas, mas você pode consertar seu repositório.
Os objetos Git devem ser imutáveis, portanto todos os seus commit mais antigos ainda devem ser válidos. De acordo com esta resposta , você pode alterar o hash
.git/refs/heads/<branch-name>para alterar o cabeçalho da ramificação em que estava trabalhando no commit anterior (você pode vê-los.git/logs/HEAD).O comentário a essa resposta diz que este método "Ainda deixa o repositório em estado quebrado, mas isso permite recuperá-lo". Não testei isso (não faço ideia de como replicar sua situação), mas presumo que a recuperação seja feita via
git gc, que excluirá a confirmação corrompida.fonte
O sistema de armazenamento do Git não é transacional, então há definitivamente uma chance de que um problema de hardware possa deixar as coisas em um estado inconsistente. Por outro lado, o Git também é muito rápido, então você teria que ser realmente azarado para ser atingido por problemas do tipo "falha de energia" (problemas sistemáticos com o disco são outra coisa). A velocidade vem em parte precisamente do fato de não ser transacional; as transações são realmente muito caras, pois precisam aguardar a confirmação de volta do disco de que os dados foram gravados. (Os bancos de dados fazem todo o tipo de coisas para tentar ocultar esse custo, mas, no final das contas, ainda pagam o preço. Alguns dos DVCSes concorrentes são transacionais e, sim, são um pouco mais lentos no mesmo hardware que o git.)
Na pior das hipóteses - uma falha catastrófica total do disco (que eu já vi acontecer) - a única maneira de recuperar um DVCS é usar o fato de que é distribuído. Se você empurrou suas alterações até muito recentemente para outro sistema e as compartilhou com muitos hosts diferentes, a recuperação é apenas uma questão de usar um desses outros locais como uma fonte de artefato, um local para obter suas ramificações ( mesmo que apenas temporariamente). Dessa forma, você recuperará a história dos ramos interessantes e poderá trabalhar novamente muito rapidamente; qualquer coisa que apague muitas cópias distribuídas de seu repositório de uma só vez é um desastre do tipo em que você não se preocupa mais com a programação posterior (pense no maior impacto meteorológico) ou é uma ação inimiga direta. (Tente não fazer esses inimigos…) Isso contrasta totalmente com os sistemas não distribuídos, onde perder o servidor central que hospeda tudo é um golpe fatal.
fonte