Git 101

Lista de bons materiais e links compartilhados por nossa equipe que dizem respeito à Git (Versionamento de Código) e outros assuntos relacionados.

• Links úteis:
  • Git Cheat Sheet
  • Tutorial interativo do git - Altamente recomendado para quem nunca utilizou git
  • Documentação oficial do git
  • Guia rápido de comandos do git
  • screencast do Fabio Akita sobre Git
  • Pro Git livro gratuito

Table of Contents Versionamento O Git Conceitos no Git Clone Commit Pull Push Fast-Forward Merge

Versionamento

"Um sistema de controle de versão (ou versionamento), é um software com a finalidade de gerenciar diferentes versões no desenvolvimento de um documento qualquer. Esses sistemas são comumente utilizados no desenvolvimento de software para controlar as diferentes versões — histórico e desenvolvimento — dos códigos-fontes e também da documentação de software." - Wikipedia O Conceito de versionamento surgiu da necessidade de vários programadores trabalharem simultaneamente na mesma base de código de forma eficiente e facil. O versionamento de código permite que diferentes programadores, através de 'commits', submetam versões ou modificações para um repositório, em que os diferentes commits serão agregados.

O Git

O Git é um sistema de versionamento distribuido, ou seja, cada cópia do código fonte é na verdade um repositório em si, permitindo por exemplo que um programador possa submeter uma versão à qualquer outro repositório, sem que este seja necessariamente o repositório central (e.g. um programador X pode submeter uma versão do código à outro programador Y diretamente, sem passar pelo github). Em um sistema Linux baseado em Debian, instalar o git é simples:

$ sudo apt-get install git

Na S1mbi0se nós utilizamos o Github como repositório central. Para configurar o acesso ao repositório central (Github) basta seguir as instruções no github: Generating SSH Keys

Conceitos no Git

Clone

Para começar a usar uma base de código existente, primeiro precisamos clonar um repositório (geralmente o central). Ao clonar um repositório, você terá em seu computador uma cópia exata da base de código, bem como dos metadados do git. Para clonar por exemplo o repositório do AudienceUI, primeiro navegue até a sua pasta de projetos (e.g. ~/projects/):

$ cd ~/projects/

Depois, com suas chaves SSH configuradas no github, execute o clone:

$ git clone git@github.com:s1mbi0se/audienceui

Pronto, agora você tem uma cópia da base de código do AudienceUI, e pode navegar e visualizar os arquivos.

$ cd audienceui/dmpAudienceUI/
$ ls

Commit

O commit, é a maneira de criar um 'pacote' com suas modificações, que pode ser submetido a outros repositórios. Por exemplo, você modificou (e/ou criou novos) arquivos na pasta templates relativos à uma nova feature HTML. Primeiro você deve adicionar os arquivos modificados/adicionados ao processo de commit. você pode adicionar arquivos específicos, caso não queira submeter todas as modificações, ou adicicionar todos:

$ # Adicionando um arquivo específico:
$ git add caminho/para/arquivo/teste.html
$ # Adicionando todos os arquivos que foram modificados/adicionados:
$ git add --all

Com os arquivos adicionados, você pode agora "gerar um pacote" com suas modificações, o tal do commit:

$ git commit -m "Implementada feature XYZ"

O parâmetro '-m' se refere à mensagem agregada ao commit, ele é obrigatório e essencial para sabermos exatamente quais modifições foram feitas neste commit.

Pull

O 'pull' é a maneira padrão de atualizar o repositório local com os commits de um repositório remoto. Ao fazer um 'pull' você estará efetivamente 'puxando' os commits do repositório remoto e aplicando-os ao reporitório local. O pull está intrinsicamente ligado ao conceito de 'Branch' ao qual não entrarei em muitos detalhes neste crash course. Para entender o conceito de branch por favor consulte o link: O Que é um branch

A sintaxe do pull é bem simples:

$ git pull

O pull efetivamente copiará os commits do repositório do github e os aplicará em seu repositório local. Se houver algum arquivo conflitante (que foi modificado por você e por algum outro, de tal modo que o git não consiga juntá-los automaticamente) você receberá um aviso de que os arquivos devem ser 'mergeados'. O Merge será tratado com mais detalhes em um tópico abaixo.

Push

O 'push' é maneira padrão de submeter commits do repositório local ao repositório remoto. Ao fazer o 'push' você estará efetivamente 'empurrando' os commits locais ao repositório remoto. A sintaxe do push é identica à do pull:

$ git push

Nota: Sempre faça um pull antes de fazer um push, para evitar Fast-Forwards.

Fast-Forward

O fast-forward é quando dois repositórios divergiram em seus commits e um pull ou push foi acionado. e.g. Um repositório originalmente em estado X foi modificado pelo programador P1 e pelo programador P2, que geraram os commits C1 e C2 respectivamente. O Programador P1 então faz push de seu commit para o github. O Programador P2, fará então um pull para garantir que esteja atualizado com a ultima versão do github, e aí então ocorrerá um fast forward. O commit C1 será trazido do servidor para o computador do progamador P2 e será 'mergeado' com o commit C2. Só depois deste merge (que pode ter sido automático ou manual), o programador P2 fará um push e enviará o commit C2 para o servidor, deixando o github atualizado com os commits C1 e C2. Note que por questões de consistência, o github bloqueia fast-forwards em seus servidores, portanto se o programador P2 não fizesse o pull, e fosse direto ao push, o git mostraria uma mensagem de erro, avisando que o repositório divergiu, e que é necessario fazer um pull e merge locais antes de submeter o seu commit.

Merge

O Merge acontece quando duas versões divergentes da base de código precisam ser agregadas. No exemplo do fast-forward acima, o merge ocorre quando P2 faz o pull. O git automaticamente tentará juntar os arquivos e gerar um novo novo commit que é o resultado da combinação C1+C2. O git faz um trabalho muito bom em merges automáticos, mas em alguns casos ele pode não conseguir mergear alguns arquivos, e gerará uma mensagem de conflito. Neste caso precisamos fazer o merge manual, via o comando:

$ git mergetool

Assim que você tiver resolvido os conflitos pela ferramenta de merge, Você terá de 'terminar' o commit de merge que o git abriu automaticamente, com:

$ git commit

Note que neste caso, não devemos passar o argumento '-m' para o commit, pois uma mensagem detalhada com o que foi mergeado é gerada pelo git. Assim que acionar o commit acima, o git abrirá um editor de arquivos em seu terminal com a mensagem que foi gerada pelo merge (você pode modificá-la se quiser), geralmente o VIM ou o nano. Salve o arquivo e feche o editor (':wq [enter]' no VIM e ctrl-o ctrl-x no nano), e está pronto o merge.