10.2 Funcionamento Interno do Git - Objetos do Git

O próximo tipo que iremos ver é a tree (árvore), que resolve o problema de armazenar o nome de arquivo e também permite armazenar de forma conjunta um grupo de 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. Um único objeto tree contém uma ou mais entradas, cada uma contendo uma referência SHA-1 para um blob ou subtree com seu modo, tipo e nome de arquivo associados. Por exemplo, a tree mais recente em um projeto deverá se parecer com algo assim:

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 que são armazenados pelo Git é algo assim:

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 apenas uma entrada - a primeira versão do do seu arquivo test.txt - você pode usar o comando 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 normais, mas é muito menos flexível - esses três modos são os únicos que são válidos para arquivos (blobs) no Git (ainda que outros modos possam ser usados para diretórios e submódulos).

Agora, você pode usar o comando write-tree para escrever a área de stage para um objeto tree. A opção -w não é necessária - chamar write-tree automaticamente cria um objeto tree a partir do estado do index caso a tree ainda não exista:

Você também pode verificar que se este é um arquivo tree:

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:

Note que essa tree tem ambas as entradas de arquivo além de que o SHA-1 de test.txt é a o SHA-1 da “versão 2” que falamos anteriormente (1f7a7a). Apenas por diversão, adicione a primeira tree como um subdiretório neste aqui. Você pode ler as trees para a área de stage chamando read-tree. Neste caso, você pode ler uma tree existente em sua área de stage como uma subtree usando a opção --prefix em read-tree:

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 você tem três trees que especificam os diferentes snapshots do seu projeto que você gostaria de rastrear, mas o problema anterior se mantém: você precisa lembrar dos três valores dos SHA-1 para encontrar os snapshots 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:

Você irá obter um valor diferente para o hash por causa das diferentes hora de criação e dados do autor. Substitua os hashes de commit e tag pelos seus próprios checksums posteriormente neste capítulo. Agora você pode olhar para o seu novo objeto commit com cat-file:

O formato para um objeto commit é simples: ele especifica a tree de nível mais alto para o snapshot do projeto neste ponto; a informação do autor/commiter (que usa as configurações user.name e user.email, além de um timestamp); uma linha em branco e então a mensagem de commit.

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 é essencialmente o que o Git faz quando você executa os comandos git add e git commit - ele armazena blobs para os arquivos que mudaram, atualiza o index, escreve as trees e escreve os objetos commit que referenciam as trees de mais alto nível e os commits que vieram imediatamente antes deles. Esses três principais objetos do Git - o blob, a tree, e o commit - são inicialmente armazenados como arquivos separados em seu diretório .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:

Mencionamos anteriormente que o cabeçalho é armazenado junto com o conteúdo. Vamos tomar um minuto para olhar como o Git armazena seus objetos. Você verá como armazenar um objeto blob - neste caso, a string “what is up, doc?” - interativamente usando a linguagem de script Ruby.

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

O Git constrói um cabeçalho que começa com o tipo de objeto, neste caso, um blob. Depois, ele adiciona um espaço seguido do tamanho do conteúdo e finalmente 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:

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). 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:

É 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, ainda que o conteúdo do blob possa ser quase qualquer coisa, o conteúdo do commit e da tree são especificamente formatados.