Git: manual de utilização e vantagens e desvantagens

O Git é uma ferramenta de controle de versão de arquivos que facilita em muito o trabalho de equipas que desenvolvem em simultâneo um projecto. Descubra as vantagens e desvantagens deste sistema de controle de versão distribuído.

O Git integra a vaga da nova geração de sistemas de controlo de versão de software (Distributed Version Control Systems – DVCS no original em inglês) - basicamente, permite o controle da versão de arquivos de um projecto editado por diversas pessoas em simultâneo.

Embora o conceito de DVCS exista desde há algum tempo, só muito recentemente é que as funcionalidades se tornaram suficientemente eficientes para captar o interesse de vários projectos open source. Foi assim, que estes decidiram migrar ou expandir os seus suportes do Subversion (sistema centralizado) para sistemas de controlo distribuídos como o Mercurial, o Git e o Bazaar.

Vantagens do Controlo de Versão Distribuído

Em termos de gestão, os DVCS contribuem para facilitar a missão das equipas de trabalho, de modo a que exerçam as suas tarefas da melhor forma, e vêm ajudar à redução de custos.

Mas os principais benefícios deste tipo de opção estão relacionados com a distribuição do processamento, acarretando vantagens em termos de redundância e/ou replicação de repositórios e permitindo alargar as possibilidades de colaboração e parceria entre programadores.

⇒ Benefícios para os programadores

• Rapidez: como os processos são operados localmente, deixa de ser preciso contactar o servidor central para proceder a operações como um commit, log ou diff.
• Autonomia: permite trabalhar em modo desconectado, em qualquer local, só sendo necessária uma conexão com a rede para troca de revisões com outros repositórios.
• Ramos individuais: contrariamente aos chamados sistemas centralizados, combinar ramos não é uma obrigação para cada commit e antes uma decisão que depende do programador; o trabalho local faz-se num ramo individual que não tem interferência com os demais ramos, mesmo em processos de sincronização entre repositórios.
• Facilidade na Fusão: os DVCS usam o rastreamento automático, o que facilita de forma significativa o processo de fusão.

⇒ Benefícios em termos de Gestão/Coordenação

• Confiabilidade: com um sistema centralizado, qualquer problema que surja no servidor vai parar todo o trabalho de desenvolvimento. Um sistema distribuído permite que a equipa continue a trabalhar e os repositórios dos programadores servem como cópias de backup, não havendo riscos de perder nada do projecto.
• Redução de custos com o servidor: o repositório "central" (se ele existir) funciona como repositório "oficial", ao invés de ter uma função de processador central dos pedidos. Assim, a carga de processamento é distribuída pelas máquinas dos programadores.

Maior complexidade é grande desvantagem dos DVCS

Mas o modelo de distribuição do controle de versão não suscita apenas vantagens - há alguns espinhos pelo meio, sendo a maior complexidade do procedimento o maior deles.

No sistema centralizado, os programadores trabalham no mesmo ramo, quer este seja principal ou de manutenção. É um processo simples e fácil de compreender e até alguém com um conhecimento limitado do controle de versão, consegue entender-se com a restante equipa.

Já no caso do sistema distribuído, as coisas são um pouco mais complexas. A estrutura peer-to-peer, os ramos privados e as fusões que aparentam estar desorganizadas podem incutir ao projecto uma ideia de confusão inicial.

Contrariamente àquilo que ocorre na versão centralizada, nos DVCS não se trata apenas de fazer commit e update. Todos os programadores envolvidos têm que ter um conhecimento mais vasto das ferramentas em uso e, idealmente, também de um modelo de trabalho com padrões de fluxos a seguir.

Apesar desta maior complexidade, o controlo de versão distribuído suscita muitas vantagens e pontos de interesse que podem até trazer benefícios para projectos que não se enquadram, à partida, no perfil recomendado.

E, de qualquer modo, este lado mais complexo é perfeitamente ultrapassável, exigindo somente maior preparação dos programadores e dos processos de trabalho. Mais do que um impedimento, pode assim, ser encarado como uma aposta na melhor formação e capacitação da equipa de trabalho com vista a criar software de excelência.

Como utilizar o Git

Download e instalação do Git

https://git-scm.com/downloads

Criar conta no bitbucket.org

Similar ao GitHub. Gratuito até 5 utilizadores.

⇒ Primeiros Passos e comandos básicos

• Configurar o nome de utilizador (importante!)

       $ git config --global user.name "nome"
       $ git config --global user.email nome@dominio.pt

• Como fazer download / clonar um repositório remoto

       $ cd ~/htdocs/
       $ git clone https://nomeutilizador@bitbucket.org/grownunder/teste-blog.git

• Como criar um repositório local
  
  $ cd ~/htdocs
$ cd <pasta-do-projecto>
$ git init
$ git add .

• Como adicionar novos ficheiros ao controlo de versão
  
  $ git add — mas tenha cuidado para não enviar ficheiros indesejados*.
$ git add . — Adiciona todos os ficheiros da pasta actual.
  
  * Os ficheiros indesejados no controlo de versões são os que são gerados durante a compilação, por ex., executáveis gerados, bibliotecas geradas, cópia automática de ficheiros, etc.. Crie um ficheiro .gitignore e adicione esses ficheiros ou pastas:
  
  *.bak
  *~ diff.txt

• Como receber / procurar alterações
  
  $ git pull — avançado: use --rebase para evitar merges desnecessários
  
  Para receber alterações num branch específico
  
  $ git checkout
$ git pull origin

• Como enviar alterações
  
  $ git commit -a — a opção “-a” faz um commit local de todos os ficheiros modificados. E uma destas opções:
$ git push — envia alterações do branch local para o remoto equivalente (ex: master -> origin/master).
$ git push --all — envia alterações de todos os branchs.
$ git push origin <source-branch> — envia alterações de um branch local para outro remoto

• Trabalhando com branchs e tags
  
  Para criar tag (ex: lançamento de versões)
  
  $ git tag -a v.1.4
$ git push --tags
  
  Para criar branch
  
  Para criar um branch e dar check-out dele:
  $ git checkout -b <nome-novo-branch>
  ou
  $ git branch <nome-novo-branch> (porém, não dá checkout ao novo branch) e para enviar ao servidor:
$ git push -u origin <nome-novo-branch> — para enviar apenas um branch
  ou
  $ git push --all — envia todos os branchs locais para o repositório de origem
  
  Para listar branchs
  
  $ git branch (lista somente os locais)
$ git branch -a (lista todos)
$ git branch -r (lista somente os remotos)
  
  Para alternar para um branch, tag ou versão
  
  $ git checkout [-f] <branch, tag ou versão> — a opção -f faz com que ficheiros modificados localmente sejam perdidos.
  
  Para remover um branch
  
  $ git branch -d <nome do branch>
  
  Para remover um branch remoto
  
  $ git branch -d -r origin/<name-of-branch>
$ git push origin :<name-of-branch> (obs.: sem o origin)
  
  Para mesclar (merge)
  
  $ git checkout <nome do branch destino> (deve “estar” no branch de destino)
$ git merge <nome do branch origem> [--no-ff] (a opção –no-ff serve para não permitir o fast forward)

• Desfazer/Reverter
  
  Desfazer um commit específico e manter o histórico
  
  $ git revert <versao>
  • <versao> pode ser um intervalo, como por ex.: 0b7cd284..642e314
  • <versao> também pode ser HEAD para desfazer o último commit
  • não use este comando quando houver alterações locais!
  
  Reverter apenas alguns ficheiros ou path
  
  $ git checkout <versao> -- <path>
  
  Desfazer ficheiro adicionado no Git por engano
  
  $ git rm --cached <file> (funciona antes e depois do commit, recomendado!) ou $ git reset HEAD <file> (apenas antes do commit)
  
  Desfazer alterações locais
  
  Para todos os ficheiros
  $ git reset --hard HEAD
  Apenas para alguns ficheiros
  $ git checkout -- <path>
  
  ---

• Outros comandos úteis:
  
  Verificar quantas versões desde o início (versão estilo SVN)
  
  O seguinte comando conta quantos commits foram dados desde a primeira versão:
  
  $ git log --pretty=oneline --all | wc -l
  
  Mostrar histórico com o nome dos ficheiros modificados
  
  $ git log –stat
  
  Verificar a diferença entre a versão actual e o último commit de um determinado ficheiro
  
  $ git diff
  
  Use diff --color-words para destacar as palavras modificadas
  
  Verificar as modificações locais
  
  $ git diff -b (a opção -b ignora os espaços em brancos)
  
  Verificar diferença entre dois branchs
  
  $ git diff .. –stat
  
  O mesmo que git diff HEAD^..HEAD
  
  $ git show
  
  Mostrar informações sobre o repositório remoto
  (é útil porque mostra a URL do repositório caso a tenha esquecido)
  
  $ git remote show origin
  
  Opção para ignorar espaços em branco e quebras de linha
  
  Use -w em combinação com com comandos de diff ou quando usar --stat para que o diff ignore todos os espaços em brancos.