quarta-feira, 6 de março de 2013

Republicando este excelente artigo.
fonte: http://blog.wylkon.com.br



Em todo projeto bem estruturado não pode faltar um bom controle de versões e entre eles irei falar do GIT.
GIT é um Software Livre para controle de versão distribuído, ou seja um software para gerenciamento de código fonte com ênfase em ser rápido. GIT foi inicialmente criado por Linus Torvalds para o desenvolvimento do kernel Linux (kernel). Cada diretório de trabalho GIT é um repositório com todos os históricos e habilidade total de controle das revisões, não dependente de acesso a uma rede ou a um servidor central.

Instalação

Para instalar o git no debian execute os seguintes comandos:
apt-get update
apt-get install git-core
Para instalar o git no Mac, via Homebrew:
brew install git
Para instalar o git no Mac, via Macports
port install git-core

Configurações de usuário

Após instalado, precisamos configurar o nome e e-mail do usuário.
git config --global user.name "Seu Nome"
git config --global user.email "seu@mail.com.br"
Essas configurações são necessárias para identificá-lo nos commits

Personalizando seu terminal

Para agilizar o trabalho criaremos shortcuts para git statusgit branchgit commit e git checkout.
git config --global alias.st status
git config --global alias.ci commit
git config --global alias.co checkout
git config --global alias.br branch
Para melhorar a visualização, podemos adicionar cores:
git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto

Comandos Básicos

GIT Clone

Para baixar qualquer projeto que esteja usando GIT como controle de versões precisamos usar o seguinte código:
git clone URLdoprojeto
E também podemos passar um nome para o projeto que estamos baixando.
git clone URLdoprojeto nomedoprojeto
Assim como no exemplo abaixo:

GIT Status

Após baixar o seu projeto e editar alguns arquivos, utilize git status para ver a situação atual dos arquivos.
git status

GIT Add

Para gravar uma mudança é necessário primeiro adicioná-la no index do projeto. Modifique alguns arquivos e então adicione seu conteúdo atualizado:
git add nomedoarquivo
Adiciona apenas 1 arquivo
git add .
Adiciona todos os arquivos

GIT Commit

Para gravar suas mudanças, use:
git commit -m "mensagem descrevendo o commit"
Caso queira adicionar todos os arquivos modificados pode fazer:
git commit -a -m "mensagem descrevendo o commit"
ou
git commit -am "mensagem descrevendo o commit"
Uma melhor forma de vizualizar o commit é abrindo a mensagem em um editor de textos, como por exemplo o Textmate, use:
git commit -a
Caso você não tenha um editor global configurado, use:
git config --global core.editor "mate -w"
Nesse caso utilizei o Textmate como editor padrão, passando o nome dele(mate). E o parametro -w(wait), é utilizado para que o GIT espere até que este arquivo temporário que é aberto seja fechado.

GIT Pull

Para atualizar sua cópia local utilize o comando:
git pull

GIT Push

Pronto, agora vamos enviar as informações para o servidor. Use:
git push

GIT Branch

Em algumas situações temos que trabalhar com mais de um branch, podemos denominar branch(ramos) como “áreas de trabalho”, imagine assim, onde você pode trabalhar com uma área e ter outra como repositório “central”, ou seja, sem risco de fazer algo errado e depois perder tudo ou conflitar o repositório master.
Para ver os branches do repositório basta usar o comando:
git branch
O branch que você se encontra está com “*”
Para criar um novo branch, usa-se:
git checkout -b novo-branch
-b = New Branch
Para manter os branches atualizados, git pull e git push devem ser suficientes. O GIT mantém cada branch separado sem interferir no outro. Contudo, mudanças sem commit vão aparecer em todos os branches.
Para mesclar as mudanças do branch master no seu branch é só fazer:
git pull .

GIT Checkout

Ignorando alterações e limpando seu branch.
git checkout nomedoarquivo
Ignora as alterações feitas num determinado arquivo.
git checkout -f
Ignora todas as mudanças não “comitadas” até o momento (deixa o seu branch limpo, mas não apaga arquivos que nunca foram “comitados”).

Pull vs Rebase

Existem dois jeitos de importar as mudanças de um repositório remoto pro repositório local. Elas são o “pull” e o “rebase”. A diferença é a forma como as mudanças locais são mantidas na hora de importar as remotas.
Imagine uma árvore de commits assim (onde local é o branch atual de desenvolvimento):
      A---B---C local
     /
D---E---F---G master
Após um “git pull” aplicado no computador local, a árvore fica:
      A---B---C---F'--G' local
     /          /
D---E---F---G ----master
Após um git push, a árvore no repositório remoto fica:
      A---B---C---F'--G'--
     /       /            \
D---E---F---G -------------A'--B'--C'--F''--G'' master
Isso não é muito interessante por serem feitos, ao todo, dois merges das mudanças locais no repositório remoto. Com mais de duas pessoas fazendo mudanças ao mesmo tempo esse método gera árvores de histórico complicadas e difíceis de entender depois, com vários merges.
Uma alternativa é usar “git pull - -rebase” em vez de “git pull”. Fazendo isso, a árvore local, que era
      A---B---C local
     /
D---E---F---G master
fica
               A'---B'---C' local
              /
D---E---F---G master
Após um “git push”, a árvore do servidor fica
               A'---B'---C'-
             /              \
D---E---F---G --------------- master
ou
D---E---F---G---A'--B'--C'----- master
o que é muito mais limpo. Mesmo com várias pessoas desenvolvendo isso tende a gerar históricos mais lineares.

GIT Cherry-pick

Você pode aplicar um commit específico na sua árvore com cherry-pick. No exemplo abaixo estamos no branch master e o commit85cd08ee1aec0fbd3cf3d696a70872639e59212f aconteceu no branch novo-ramo. Ele vai aplicar apenas esse commit em master.
git cherry-pick 85cd08ee1aec0fbd3cf3d696a70872639e59212f
Isso é útil quando você corrigiu um bug em um ramo de desenvolvimento e quer replicá-lo no ramo principal.

Resolvendo conflitos

Quando um merge não é resolvido automaticamente pelo git ele indica isso claramente. Você não vai conseguir dar um commit. Tanto commit quanto status vão mostrar os arquivos que precisam resolver os conflitos:
O GIT vai marcar os conflitos no arquivo usando marcadores de conflito. Abaixo podemos ver um conflito marcado com duas versões:
<<<<<<< variant A
Uma versão
>>>>>>> variant B
Outra versão
======= end
Para resolver o conflito, precisamos apagar as linhas marcadoras de conflito e após efetuar a correção fazer um git pullgit ci -a -m"Mensagem referente a correção".

GIT Stash

Imagine que você precise parar de trabalhar numa feature, mas não quer perder as coisas que já fez, e precisa começar outra feature.
Se você utilizar git checkout -f, simplesmente apagará tudo.
Então nesse caso use:
git stash
No exemplo abaixo faço uma pequena demonstração:
Para listar os stashes existentes:
git stash list
Para aplicar o que foi “guardado”, use:
git stash apply
Nesse caso ele adiciona sempre adiciona o último stash guardado
Para aplicar o que foi “guardado” de um stash anterior use:
git stash apply stash@{0}
Para apagar o último stash salvo, use:
git stash drop
Removendo um stash específico, passando o índice do mesmo:
git stash drop stash@{1}

Fontes de Consulta

0 comentários: