Get best of the week

Guia Git NĂșmero da peça 1: tudo o que vocĂȘ precisa saber sobre o diretĂłrio .git



Começar a usar o Git Ă© como visitar um novo paĂ­s cujo idioma vocĂȘ nĂŁo conhece. Embora esteja claro onde vocĂȘ estĂĄ e para onde ir, tudo estĂĄ bem, mas se vocĂȘ se perder, grandes problemas começam.

Existem vĂĄrios tutoriais sobre comandos do Git publicados na Internet, mas neste artigo, o trabalho do Git Ă© examinado mais profundamente do que apenas aprender os comandos.

Esta Ă© a primeira parte do guia Git do blog Pierre de Wulf traduzido pela equipe do Mail.ru Cloud Solutions . 

Novos usuårios acham difícil se sentir confortåvel com o Git. Essa é uma ferramenta poderosa, mas, infelizmente, não é muito fåcil de aprender. Muitos conceitos novos, comandos que executam açÔes diferentes, se o arquivo é passado como parùmetro ou não, feedback pouco claro ...

Provavelmente, a Ășnica maneira de superar todas essas dificuldades Ă© aprender um pouco mais do que apenas git commit / push, para entender como o Git funciona.

Pasta .Git


Quando vocĂȘ cria um novo repositĂłrio com o comando git init, o Git cria uma pasta mĂĄgica, .git. Ele contĂ©m tudo o que vocĂȘ precisa para o Git funcionar. Se vocĂȘ deseja remover o Git do seu projeto, mas deixar os arquivos do projeto em disco, basta excluir a pasta .git. Embora quem possa precisar disso?

    ├── HEAD
    ├── branches
    ├── config
    ├── description
    ├── hooks
    │ ├── pre-commit.sample
    │ ├── pre-push.sample
    │ └── ...
    ├── info
    │ └── exclude
    ├── objects
    │ ├── info
    │ └── pack
    └── refs
     ├── heads
     └── tags


Aqui estĂĄ o conteĂșdo de uma pasta .git tĂ­pica antes do seu primeiro commit:

  1. CABEÇA - consideraremos isso mais tarde.
  2. config — , , , url , , email . git config, .
  3. description — gitweb .
  4. hooks — , Git. , , / commit/rebase/pull
 . push .
  5. Os arquivos info - exclude - que vocĂȘ nĂŁo deseja incluir no repositĂłrio sĂŁo descritos aqui. A funcionalidade desse arquivo Ă© a mesma do arquivo .gitignore, exceto que ele nĂŁo Ă© transferido para o repositĂłrio. Na prĂĄtica, geralmente .gitignore Ă© suficiente para todas as tarefas.

O que hĂĄ dentro do commit?


Cada vez que vocĂȘ cria um arquivo e confirma as alteraçÔes, o Git arquiva o arquivo e o armazena em sua estrutura de dados. Um objeto arquivado Ă© criado com um nome exclusivo e armazenado na pasta de objetos.

Antes de examinar a pasta do objeto, vamos esclarecer o que é a confirmação. Uma confirmação é uma pepita do estado atual dos arquivos em uma pasta de trabalho, mas não apenas isso.

De fato, quando vocĂȘ confirma alteraçÔes, o Git faz apenas duas coisas:

  1. Se o arquivo na pasta de trabalho nĂŁo foi alterado, ele simplesmente adiciona o nome do arquivo compactado (hash) ao instantĂąneo.
  2. Se o arquivo na pasta de trabalho foi alterado, ele o compacta, coloca na pasta de objetos e adiciona o nome do arquivo compactado (hash) ao instantĂąneo.

Obviamente, aqui tudo Ă© descrito de uma maneira um pouco simplificada, no entanto, isso Ă© suficiente para entender os processos em andamento.

Assim que um instantùneo é tirado, ele também é arquivado e nomeado com um hash e, em seguida, colocado na pasta de objetos.

├── 4c
│ └── f44f1e3fe4fb7f8aa42138c324f63f5ac85828 // hash
├── 86
│ └── 550c31847e518e1927f95991c949fc14efc711 // hash
├── e6
│ └── 9de29bb2d1d6434b8b29ae775ad8c2e48c5391 // hash
├── info // let's ignore that
└── pack // let's ignore that too


É assim que a pasta de objetos se parece depois que eu criei o arquivo_1.txt e o confirmei. Observe que, se o hash do seu arquivo começar com "4cf44f1e ...", o Git o salvará com o nome "f44f1e ..." em uma subpasta chamada "4c". Assim, os arquivos serão dispostos em 256 subpastas e cada um não terá muitos arquivos.

Como vocĂȘ pode ver, temos trĂȘs hashes. Um para o arquivo_1.txt, o segundo para uma captura instantĂąnea feita no commit. Para que serve o terceiro? O terceiro hash Ă© criado porque o commit tambĂ©m Ă© um objeto, tambĂ©m Ă© arquivado e colocado na pasta de objetos.

VocĂȘ precisa se lembrar que o commit consiste em quatro coisas:

  1. O nome (hash) da captura instantĂąnea do diretĂłrio de trabalho.
  2. Comente.
  3. InformaçÔes sobre quem executou o commit.
  4. O hash do commit pai.

Veja vocĂȘ mesmo o que acontece se vocĂȘ descompactar o arquivo de confirmação:

git cat-file -p 4cf44f1e3fe4fb7f8aa42138c324f63f5ac85828

E aqui estĂĄ o que vocĂȘ verĂĄ:

tree 86550c31847e518e1927f95991c949fc14efc711
author Pierre De Wulf 
<test[@gmail.com](mailto:pierredewulf31@gmail.com)> 1455775173 -0500
committer Pierre De Wulf 
<[test@gmail.com](mailto:pierredewulf31@gmail.com)> 1455775173 -0500
commit A

VocĂȘ vĂȘ, como esperado, o hash do instantĂąneo, o autor e o comentĂĄrio do commit. Duas coisas sĂŁo importantes aqui:

  1. O hash do instantùneo "86550 ..." também é um objeto e pode ser visto na pasta de objetos.
  2. Como esse Ă© o primeiro commit, ele nĂŁo possui um commit pai.

O que realmente estĂĄ na foto?

git cat-file -p 86550c31847e518e1927f95991c949fc14efc711
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 file_1.txt

Aqui vemos o objeto que estava em nosso armazenamento de objetos, o Ășnico objeto em nossa imagem.

Ramo, tags, HEAD sĂŁo a mesma coisa


Agora vocĂȘ entende que tudo no Git pode ser obtido atravĂ©s do hash correto. Vamos dar uma olhada no HEAD agora. EntĂŁo o que hĂĄ lĂĄ?

cat HEAD
ref: refs/heads/master

NĂŁo hĂĄ hash, e isso faz sentido, pois HEAD Ă© um ponteiro para o topo do ramo com o qual vocĂȘ estĂĄ trabalhando. Se vocĂȘ olhar o arquivo refs / heads / master, verĂĄ:

cat refs/heads/master
4cf44f1e3fe4fb7f8aa42138c324f63f5ac85828
 

Parece familiar? Naturalmente, Ă© um hash do primeiro commit! Isso mostra que tags e ramificaçÔes sĂŁo apenas ponteiros para uma confirmação. Entendendo isso, Ă© possĂ­vel excluir todas as tags que vocĂȘ deseja, todos os ramos que deseja e o commit que eles apontaram permanecerĂĄ no lugar. A Ășnica coisa, serĂĄ mais difĂ­cil acessĂĄ-lo. Se vocĂȘ quiser saber mais sobre isso, consulte o livro git .

Último comentário


Depois de ler, deve ficar Ăłbvio para vocĂȘ que tudo o que o Git faz Ă© arquivar sua pasta de trabalho e colocĂĄ-la na pasta de objetos com algumas informaçÔes adicionais. Se vocĂȘ estiver familiarizado o suficiente com o Git, terĂĄ controle total sobre quais arquivos serĂŁo incluĂ­dos no commit e quais nĂŁo.

Acredito que a confirmação nĂŁo Ă© um instantĂąneo da pasta de trabalho, mas um instantĂąneo dos arquivos que vocĂȘ deseja confirmar. E onde o Git armazena a lista de arquivos que vocĂȘ deseja confirmar? Ele salva esta lista em um arquivo de Ă­ndice. NĂŁo vamos nos aprofundar nessa questĂŁo; se vocĂȘ estiver interessado, mais detalhes podem ser encontrados aqui .

Traduzido com suporte do Mail.ru Cloud Solutions .

O que mais se pode ler :

  1. MĂ©todos de cache simples no IC do GitLab: um guia de imagens .
  2. -Agile .
  3. .

More articles:


All Articles