10.2 Git Internals (Por Dentro do Git) - Objetos do Git

O próximo tipo é a tree, que armazena nomes e permite reunir arquivos. O Git armazena o conteúdo em uma maneira similar a um sistema de arquivos UNIX, porém um pouco simplificado. Todo o conteúdo é armazenado como objetos tree e blob, com as trees correspondendo a entradas de um diretório UNIX e blobs correspondendo mais ou menos a inodes ou conteúdos de arquivos. Uma tree contém entradas com o SHA-1 de um blob ou subtree, seu modo, tipo e nome. Suponha que a tree mais recente seja semelhante a esta:

A sintaxe master^{tree} especifica o objeto tree que é apontado pelo último commit em sua branch master . Note que o subdiretório lib não é um blob, mas uma referência para outra tree:

Conceitualmente, os dados armazenados se parecem com isto:

Você pode criar facilmente a sua própria tree. O Git normalmente cria uma tree a partir do estado da sua área de stage ou index e escrevendo uma série de objetos tree a partir dela. Então, para criar um objeto tree, você primeiro precisa popular um index adicionando alguns arquivos. Para criar um index com a primeira versão de test.txt, use git update-index. Você usa esse comando para adicionar artificialmente a versão anterior do arquivo test.txt à nova área de stage. Você precisa passar a ele a opção --add porque o arquivo ainda não existe em sua área de stage (você nem precisa ter uma área de stage ainda) e a opção --cacheinfo porque o arquivo que você está adicionando não está em seu diretório mas está no seu banco de dados. Depois você especifica o modo, o SHA-1 e o nome do arquivo:

Neste caso, você está especificando um modo 100644, o que significa se trata de um arquivo normal. Outras opções são 100755, o que significa que é um arquivo executável; e 120000, que especifica um link simbólico. O modo vem dos modos UNIX, mas esses três são os únicos válidos para arquivos (blobs) no Git; outros são usados para diretórios e submódulos.

Use git write-tree para gravar a área de stage em uma tree. -w não é necessário – o comando cria uma tree a partir do index caso ela ainda não exista:

Confirme que esse é um objeto tree usando git cat-file:

Você pode criar um novo arquivo tree com a segunda versão de test.txt, além de um novo arquivo:

Sua área de stage agora tem a nova versão de test.txt, bem como o novo arquivo new.txt. Escreva essa tree (grave o estado da área de stage ou index para um objeto) e veja como ela se parece:

Essa tree contém duas entradas, e o SHA-1 de test.txt é o da “versão 2” (1f7a7a). Apenas por diversão, adicione a primeira tree como um subdiretório neste aqui. Leia trees para a área de stage com git read-tree. Use --prefix para ler uma tree como subtree:

Se você criasse um diretório de trabalho a partir da nova tree que você criou, você teria os dois arquivos no nível mais alto do diretório de trabalho e um subdiretório chamado bak que conteria a primeira versão do arquivo test.txt. Você pode pensar nos dados que o Git armazena para essas estruturas como sendo algo assim:

Agora há três trees para os snapshots, mas é preciso lembrar seus três SHA-1 para recuperá-los. Você também não tem nenhuma informação sobre quem salvou os snapshots, quando eles foram salvos, ou porque eles foram salvos. Essas são informações básicas que o objeto commit armazena para você.

Para criar um objeto commit, você chama commit-tree e especifica o SHA-1 de uma única tree e quais objetos commit precedem diretamente ele, se houver. Começando com a primeira tree que você escreveu:

Examine o novo objeto commit com git cat-file:

Um commit especifica a tree do snapshot; os pais; autor e committer; uma linha em branco; e a mensagem.

A seguir, você irá escrever outros dois objetos commit, cada um referenciando o commit que veio diretamente antes dele:

Cada um dos três objetos commit aponta para uma das três trees de snapshot que você criou. Curiosamente, você tem agora um histórico do Git real que você pode ver com o comando git log, se você executá-lo no SHA-1 do último commit:

Incrível. Você acabou de fazer operações de baixo nível para criar um histórico do Git sem usar nenhum dos comandos de front-end. É isso que git add e git commit fazem: armazenam blobs, atualizam o index e gravam trees e commits que referenciam seus antecessores. Blob, tree e commit são armazenados inicialmente como arquivos separados em .git/objects. Estes são todos os objetos no diretório de exemplo, comentados com o que eles armazenam:

Se você seguir as referências internas, você obterá um grafo de objetos mais ou menos como este:

Um cabeçalho é armazenado com cada objeto enviado ao banco de dados. Vamos examinar como o Git armazena objetos. Você armazenará interativamente em Ruby um blob com a string “what is up, doc?”.

Você pode iniciar o modo interativo do Ruby com o comando irb:

Primeiro, o Git constrói um cabeçalho que identifica o tipo – nesse caso, blob. Ele acrescenta um espaço, o tamanho em bytes e um byte nulo:

O Git concatena o cabeçalho e o conteúdo original e então calcula o checksum SHA-1 do novo conteúdo. Você pode calcular o valor SHA-1 de uma string em Ruby incluindo a biblioteca SHA1 digest com o comando require e então chamando Digest::SHA1.hexdigest() com a string:

Compare com a saída de git hash-object. Usamos echo -n para não acrescentar uma quebra de linha.

O Git comprime o novo conteúdo com zlib, o que você pode fazer em Ruby com a biblioteca zlib. Primeiro, você precisa incluir a biblioteca e então executar Zlib::Deflate.deflate() no conteúdo:

Por último, você irá salvar o seu conteúdo comprimido com zlib em um objeto no disco. Você irá determinar o caminho do objeto que você quer escrever (sendo os dois primeiros caracteres do valor do SHA-1 o nome do subdiretório, e os últimos 38 caracteres sendo o nome do arquivo dentro desse diretório). ==== Objetos de Commit (Commit Objects) Em Ruby, você pode usar a função FileUtils.mkdir_p() para criar o subdiretório se ele não existir. Depois, abra o arquivo com File.open() e escreva o conteúdo previamente comprimido com zlib no arquivo chamando write() no file handle resultante:

Verifique o conteúdo com git cat-file:

É isso - você criou um objeto blob do Git válido.

Todos os objetos são armazenados do mesmo jeito, apenas com diferentes tipos - em vez da string blob, o cabeçalho começará com commit ou tree. Além disso, embora o conteúdo de um blob possa ser quase qualquer coisa, os conteúdos de um commit ou tree estão formatados de uma forma muito específica.