Git Basics

Este post é um overview do primeiro capítulo da documentação do Git.

O que é o Git, como surgiu, controle de versão?

Controle de versão pode ser feito de diversas formas. O simples fato de organizar pastas de backup por data, ex: 2018-02-22-Backup, e em outro dia criar outra pasta com o nome 2018-03-22-Backup, já faz com que tenhamos um controle de versão. O problema é que dessa forma se torna um controle de versão pouco vantajoso, pois precisamos verificar os arquivos um a um em busca de alterações e também incluir novos arquivos.

Para solucionar este problema foram desenvolvidos os VCS’s (Version Control System). Entre os tipos de VCS, estão:

      • Sistemas Locais de Controle de VersãoConsiste em um Banco de Dados simples que mantêm todas as alterações nos arquivos sob controle de revisão.

        • Sistemas Centralizados de Controle de Versão

          Tem um único servidor que contém todos os arquivos de controle de versão, e um número de clientes que usam arquivos a partir desse lugar central

        • Sistemas Distribuídos de Controle de Versão

Clientes não somente usam o estado mais recente dos arquivos: eles duplicam localmente o repositório completo, cada clone é um backup completo de todos os dados.  É aqui que o Git se encaixa. Neste formato de controle de versão, todos os colaboradores do projeto possuem uma cópia inteira do projeto, logo, o número de backups limita-se ao número de colaboradores do projeto.

 

ORIGEM

A origem do Git surge em 2005 a partir de um desentendimento entre os desenvolvedores que colaboravam com o projeto do Kernel do Linux e a empresa que mantinha o BitKeeper, que era um software de DVCS. Com este desentendimento, a empresa decidiu monetizar o software, o que causou um certo desconforto com a comunidade.

Liderada pelo próprio criador do Linux, Linus Torvalds, e com vários conhecimentos e experiências adquiridas durante o uso do BitKeeper, a comunidade começou o desenvolvimento do Git. Com o objetivo de atender aos seguintes princípios:

  • Velocidade
  • Simplicidade
  • Não-linear (branching), trabalhar em múltiplos “ramos” ao mesmo tempo.
  • Completamente distribuído.
  • Capacidade de trabalhar com projetos grandes (velocidade e tamanho dos dados)

 

GIT BASICS

  • Snapshots, not differences.

O Git não trabalha armazenando a diferença dos arquivos e sim as diferenças do sistema de arquivos como um todo.

Diferenças entre arquivos

Diferença no filesystem

 

  • Quase toda operação é localIsso faz com que o Git trabalhe muito rapidamente, além de garantir a usabilidade offline, pois como o repositório está local, não é necessário internet para utilizá-lo.
  • IntegridadeTudo no git é check-summed com hash SHA-1. Isso significa que se uma vírgula for alterada no arquivo, o Git saberá pois a hash do arquivo não será mais a mesma.
  • O Git geralmente só adiciona dadosDepois de um commit, é muito difícil perder dados.
    Provê certa segurança, pois podemos fazer testes tranquilamente, sem medo de perder nada.

OS TRÊS ESTADOS

Working Directory
É o último snapshot dos arquivos que é ‘descomprimido’ do banco de dados no “.git directory”.

Staging Area
É um arquivo que armazena as informações sobre o que irá no próximo commit.

.git directory
É a parte mais importante do Git, copiado quando um projeto é clonado.

Então, podemos dizer que um workflow regular do Git possui os seguintes passos:

Modificar arquivos no Working Directory => Adicionar Snapshots dos estados atuais na Staging Area => Fazer um commit, que armazena o que está na Staging Area de forma permanente no .git directory.

 

ALGUNS COMANDOS DO GIT

$ git add <arquivo> - Adiciona o arquivo na Staging Area para “enviá-lo” no próximo commit.
$ git diff –cached - Visualiza os arquivos que estão na Staging Area.
$ rm <arquivo> - Comando do linux para remover arquivo.
$ git rm <arquivo> - Remove o arquivo e já adiciona a remoção na Staging Area
$ git rm <arquivo> –cached - Torna o arquivo untracked.
$ git mv <file_from> <file_to> - Mesma funcionalidade do comando “mv” do Linux, porém o Git já adiciona as mudanças na Staging Area.
Visualizando o histórico dos commits:
$ git log {
-p -<n> - Visualiza os <n> últimos commits e -p traz o ‘git diff’ do commit
–pretty=format:”%h, %an, %s” –graph - Formata a saída do log de acordo com os parâmetros passados.
–grep <keyword> - Funcionamento igual ao comando grep do Linux.
-Sfunction_name - Pesquisa pela String passada após o parâmetro (function_name).
};
Desfazendo coisas:
$ git commit -m “Initial commit”
$ git add <forgotten_file>
$ git commit –amend
$ git reset HEAD <file>
$ git checkout <file>

“Tudo o que foi perdido e não foi commitado, provavelmente não será visto de novo.”

Documentation, Git.


Criando aliases (atalhos):
$ git config –global alias.<alias> <command>

$ git config –global alias.st status
$ git config –global alias.unstage ‘reset HEAD –‘

 

BRANCHING

Conhecido como o Killer’s feature do Git, significa que você diverge da linha principal de desenvolvimento e continua a trabalhar sem bagunçar com a linha principal.

“O Git encoraja workflows que usam branches e merges frequentemente, até mesmo multiplas vezes em um dia.”

Para entendermos melhor como as Branches funcionam, conforme orientação da documentação, precisamos entender como o Git armazana seus dados.

Quando fazemos um commit, o git armazena um objeto que contem um “indicador” para o snapshot daquele conteúdo que você stageou.

No exemplo abaixo, foram criados 3 novos arquivos, o git cria um blob para cada arquivo, que nada mais é do que um objeto que contém uma hash SHA-1. Cria também uma tree, onde armazena as hashs dos blobs que foram criados, e no commit é colocado a hash da tree, além de outros metadados, como nome do autor, hash do commit

Nos próximos commits que serão criados, o Git armazenará o hash do commit anterior, para futuramente obter uma espécie de timeline, para saber quem é filho de quem, qual é a ordem dos commits.

Voltando ao assunto, o que é a Branch então?
A branch nada mais é do que um indicador para o snapshot atual. A imagem abaixo exemplifica o conceito.

Podemos reparar que temos duas branches, a master e a testing, cada uma apontando para um commit.

Quando fazemos um merge em um caso como no da imagem acima, o que o git fará na verdade é verificar se ambos os commits possuem o mesmo “commit pai“, se sim, será realizado um merge “fast forward“, que nada mais é do que um diff entre os commits que o git realiza e implementa as diferenças. Caso o commit anterior não seja o commit pai de ambos, o git realizará um merge utilizando a “recursive strategy” como demonstrado na imagem abaixo.

É uma busca pelo commit em comum, o Git vai voltando até achar o “ancestral comum” e a partir dele ver o que mudou e fazer o merge.

FINALIZANDO

Com as informações presentes no capítulo Git Basics da documentação já é possível utilizar o Git em seus projetos. Simples de utilizar e pode nos economizar uma baita dor de cabeça.

É isso, espero que tenham gostado e conseguido reter algum conhecimento deste post. Caso surja alguma dúvida ou se quiser se aprofundar melhor no assunto, a documentação do Git é muito bem organizada e bem completa.

Obrigado por ler!

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>