10.7 Git Internals (Por Dentro do Git) - Manutenção e Recuperação de Dados

Ocasionalmente, o Git automaticamente executa um comando chamado “auto gc”. Na maior parte do tempo, este comando não faz nada. No entanto, se há muitos objetos loose (objetos soltos que não estão dentro de um packfile) ou muitos packfiles (arquivos de pacotes), o Git inicializa uma versão do comando git gc de pleno direito. O “gc” significa garbage collect (coleta de lixo), e o comando faz algumas coisas: ele junta todos os objetos soltos e os coloca em um packfile, consolida os packfiles em um grande packfile, e apaga os objetos que não são alcançáveis a partir de nenhum commit e que têm alguns meses de idade.

Você pode rodar um auto gc manualmente da seguinte maneira:

Novamente, geralmente isso não faz nada. Você deve ter mais ou menos uns 7.000 objetos do tipo loose (objetos soltos) ou mais de 50 do tipo packfiles para que o Git dispare um comando gc de fato. Você pode modificar esses limites com as definições de configuração gc.auto e gc.autopacklimit, respectivamente.

A outra coisa que o gc fará é empacotar as suas referências para dentro de um único arquivo. Suponha que o seu repositório contenha os seguintes branches e tags:

Se você rodar o git gc, você não terá mais esses arquivos no diretório refs. O Git vai movê-los visando a eficiência para um arquivo chamado .git/packed-refs que se parece com isso:

Se você atualizar alguma referência, o Git não editará esse arquivo, em vez disso, ele criará um novo arquivo em refs/heads. Para obter o SHA-1 apropriado para uma determinada referência, o Git verifica por essa referência no diretório refs e então verifica o arquivo packed-refs como alternativa. Então se você não conseguir achar a referência no diretório refs, ela provavelmente estará no seu arquivo packed-refs.

Note a última linha do arquivo, que começa com um ^. Isto significa que a tag diretamente acima é uma tag anotada (annotated tag) e que a linha é o commit para o qual a tag apontada está orientada.

Em algum ponto na sua jornada com o Git, você pode perder um commit acidentalmente. Geralmente, isto acontece porque você forçou a deleção de um branch que tinha algum trabalho, e acontece que você afinal de contas o queria; ou você fez um hard-reset num branch, consequentemente abandonando commits que você desejava manter. Assumindo que isto aconteça, como você pode recuperar os seus commits de volta?

Aqui está um exemplo que faz um hard-reset no branch master do seu repositório de testes para um commit mais antigo e em seguida recupera os commits perdidos. Primeiro, vamos verificar onde o seu repositório está neste exato ponto:

Agora, mova o branch master de volta para o commit do meio:

Você efetivamente perdeu os dois commits superiores – você não tem nenhum branch a partir do qual aqueles commits sejam alcançáveis. Você precisa encontrar o SHA-1 do último commit e então adicionar um branch que aponte para ele. O truque é encontrar aquele último commit SHA-1 – não é como se você o tivesse memorizado, certo?

Muitas vezes, a maneira mais rápida é usar uma ferramenta chamada git reflog. Conforme você está trabalhando, o Git grava silenciosamente qual é o seu HEAD toda vez que você o altera. A cada vez que você comita ou muda de branch, o reflog é atualizado. O reflog também é atualizado pelo comando git update-ref, o que é outro motivo para usá-lo em vez de simplesmente escrever o valor do SHA-1 nos seus arquivos de ref, como vimos em Referências do Git. Você pode ver por onde você esteve a qualquer momento, executando git reflog:

Aqui podemos ver os dois commits dos quais fizemos checkout, entretanto não há muita informação aqui. Para ver a mesma informação de uma forma muito mais útil, nós podemos executar git log -g, o qual dará a você uma saída de log normal para o seu reflog.

Parece que o commit mais abaixo é o que você perdeu, então você pode recuperá-lo criando um novo branch naquele commit. Por exemplo, você pode criar um branch chamado recover-branch a partir daquele commit (ab1afef):

Legal – agora você tem um branch chamado recover-branch onde o seu branch master costumava estar, fazendo com que os dois primeiros commits sejam alcançáveis de novo. A seguir, suponha que a sua perda por alguma razão não estava no reflog – você pode simular isto removendo a recover-branch e apagando o reflog. Agora os dois primeiros commits não são alcançáveis por mais nada:

Pelo fato de os dados do reflog serem mantidos no diretório .git/logs/, você efetivamente não tem nenhum reflog. Como você consegue recuperar esse commit a esta altura? Uma forma é usar o utilitário git fsck, o qual verifica a integridade do seu banco de dados. Se você executá-lo com a opção --full, ele mostra a você todos os objetos que não são apontados por outro objeto:

Neste caso, você consegue ver o seu commit faltante depois do texto “dangling commit” (commit solto/perdido). Você pode recuperá-lo da mesma forma, adicionando um branch que aponte para aquele SHA-1.

Há muitas coisas ótimas sobre o Git, mas um recurso que pode causar problemas é o fato de que um git clone baixa o histórico inteiro do projeto, incluindo cada versão de cada arquivo. Isto é bom se o projeto inteiro se trata de código-fonte, pois o Git é altamente otimizado para comprimir esses dados de maneira eficiente. Porém, se alguém em algum momento no histórico do seu projeto adicionou um único arquivo enorme, todo clone para todo o sempre será forçado a baixar aquele arquivo grande, mesmo que ele tenha sido removido do projeto no commit logo em seguida. Como ele é alcançável a partir do histórico, ele sempre estará lá.

Isto pode ser um enorme problema quando você estiver convertendo repositórios do Subversion ou Perforce para o Git. Como você não baixa o histórico inteiro naqueles sistemas, este tipo de adição traz poucas consequências. Se você fez uma importação de outro sistema ou descobriu de alguma forma que o seu repositório está bem maior do que deveria ser, veja aqui como você pode encontrar e remover grandes objetos.

Fique avisado: esta técnica é destrutiva para o histórico dos seus commits. Ela reescreve todo objeto de commit a partir da tree mais antiga que você precisa modificar para remover uma referência de arquivo grande. Se você fizer isto imediatamente após uma importação, antes de alguém ter começado a basear seu trabalho no commit, você não terá problemas – do contrário, você terá de notificar todos os contribuidores que eles devem fazer o rebase de seus trabalhos para os seus novos commits.

Para demonstrar, você vai adicionar um arquivo grande no seu repositório de testes, removê-lo no commit seguinte, encontrá-lo, e removê-lo permanentemente do repositório. Primeiro, adicione um objeto grande ao seu histórico:

Ops – você não queria adicionar um enorme tarball ao seu projeto. Melhor se livrar disto:

Agora, rode o gc no seu banco de dados e veja quanto espaço você está usando:

Você pode executar o comando count-objects para ver rapidamente a quantidade de espaço que você está consumindo:

A entrada size-pack é o tamanho dos seus packfiles em kilobytes, então você está utilizando quase 5MB. Antes do último commit, você estava usando algo mais perto de 2K – claramente, remover o arquivo do commit anterior não o removeu do seu histórico. Toda vez que alguém clonar este repositório, terá que baixar todos os 5MB apenas para obter este projeto pequeno, porque você acidentalmente adicionou um arquivo grande. Vamos nos livrar disto.

Primeiro você tem que encontrá-lo. Neste caso, você já sabe de que arquivo se trata. Mas suponha que você não soubesse; como você identificaria qual ou quais arquivos estariam tomando tanto espaço? Se você rodar git gc, todos os objetos estarão em um packfile; você pode identificar os grandes objetos executando um outro comando plumbing chamado git verify-pack e ordenando pelo terceiro campo da saída, que é o tamanho do arquivo. Você também pode repassá-lo pelo pipe usando o comando tail porque você está interessado somente nos últimos poucos maiores arquivos:

O objeto grande está no final: 5MB. Para descobrir que arquivo é este, você usará o comando rev-list, que você usou rapidamente em Impondo um Formato de Mensagem de Commit Específico. Se você passar a flag --objects para o rev-list, ele lista todos os SHA-1s de commits e também os SHA-1s de blobs com os caminhos de arquivos associados a eles. Você pode usar isso para encontrar o nome do seu blob:

Agora, você precisa remover este arquivo de todas as trees no seu passado. Você pode ver com facilidade quais commits modificaram esse arquivo:

Você precisa reescrever todos os commits seguintes a 7b30847 para remover totalmente este arquivo do seu histórico no Git. Para fazer isso, você usa o filter-branch, que você usou em Reescrevendo o Histórico:

A opção --index-filter é similar à opção --tree-filter usada em Reescrevendo o Histórico, exceto que, em vez de passar um comando que modifica arquivos checados no disco, você estará modificando sua staging area (área de preparação) ou o index em cada vez.

Em vez de remover um arquivo específico com algo como rm file, você terá de removê-lo com git rm --cached – você precisa removê-lo a partir do índice, não a partir do disco. A razão para se fazer desta forma é a velocidade – porque o Git não tem que efetuar checkout de cada revisão pro disco antes de rodar o seu filtro, o processo pode ser muito, muito mais veloz. Você pode realizar a mesma tarefa usando --tree-filter caso queira. A opção --ignore-unmatch para o git rm diz a ele para não falhar caso o padrão que você está tentando remover não estiver ali. Por fim, você pede para o filter-branch reescrever o seu histórico apenas a partir do commit 7b30847 em diante, pois você sabe que é de onde o problema se originou. Do contrário, ele irá começar a partir do início e vai, de maneira desnecessária, levar mais tempo.

Seu histórico não contém mais nenhuma referência a esse arquivo. Entretanto, o seu reflog e um novo conjunto de refs que o Git adicionou sob .git/refs/original quando você rodou o filter-branch ainda contêm, então você terá que removê-los para então reempacotar o banco de dados. Você precisa se livrar de qualquer coisa que tenha um ponteiro para esses antigos commits antes de reempacotar:

Vamos ver quanto espaço você salvou.

O tamanho do repositório empacotado baixou para 8K, o que é bem melhor que 5MB. Você pode ver pelo valor do tamanho que o grande objeto ainda está nos seus loose objects, portanto não se foi; mas ele não será transferido num push ou num clone subsequente, que é o mais importante. Se você quisesse muito, você poderia remover o objeto por completo executando o git prune com a opção --expire: