T
U
T
O
R
IA
L
Git no Controle
Caso já tenha feito alguma mudança em um código ou texto em que estava trabalhando, e depois percebeu que a versão anterior era melhor, você precisa de um software de controle de versão. Mostraremos como o Git pode ajudar.
por Juliet Kemp
C
om softwares de controle de versão, é possível controlar o histórico do seu projeto e reverter qualquer edição caso mude de ideia. Além disso, é possível criar e controlar múltiplas versões ou va-riações do seu trabalho. Projetos de software invariavelmente usam al-guma forma de controle de versão, e o Git [1] é cada vez mais usado. O Git foi originalmente criado por Linus Torvalds, para ser utilizado pela equipe de desenvolvimento do kernel do Linux, mas sua flexibilida-de, velocidade e estrutura altamente distribuída popularizaram o uso em todos os tipos de projetos.O Git é projetado para ser alta-mente distribuído, muito rápido e flexível. “Distribuído” significa que, diferentemente de outros sistemas de controle de versão, como o CVS
ou o Subversion, o Git não necessita de um repositório central definitivo. Em vez disso, todos os repositórios têm o mesmo status, e qualquer um deles pode ser atualizado com base em qualquer outro – o que é muito bom para projetos cooperativos [2]. Um dos recursos centrais do Git é que ele foi projetado para supor-tar desenvolvimento não linear: ele espera que mudanças sejam unidas repetidamente conforme vão sendo passadas por revisores e desenvolve-dores diferentes. Isso significa que é fácil unir variações e até mesmo árvores inteiras, independente do fato de terem um ancestral comum. Diferente de outros sistemas de controle de versão, o Git facilita a inclusão de arquivos sem versão em uma árvore já existente. Isso é ótimo para projetos com
desenvolvimen-to extremamente distribuído, mas também oferece uma flexibilidade ímpar para o uso individual.
Seu primeiro
repositório Git
Para começar, instale o pacote do core do Git (no Debian/Ubuntu e Fedora) para ter o básico; o pacote
git -doc (documentação) também é interessante. Vários outros pacotes de extensão estão disponíveis, tais como o git -svn, que permite uma interoperabilidade com o Subversion, e o gitweb, que possui uma interface web. Outra maneira é instalar o Git do código fonte [3].
Depois que o Git estiver instala-do, é fácil configurar seu primeiro repositório. A natureza distribuída do Git significa que cada cópia do
Ja sm in M er d an , 1 23 R F
Figura 1 Configurar um diretório como repositório Git é simples, através da linha de comando.
trabalho contém seu próprio reposi-tório (no subdirereposi-tório .git), não em uma localização central, como nos sistemas CVS e SVN.
Portanto, se já há um diretório que precisa ser posto sob controle de versão, o processo é extrema-mente direto:
cd my_directory git init git add . git commit
Quando o diretório estiver sob o controle do Git (figura 1), tente adicionar outro arquivo (newfile) e digite então git status. Uma men-sagem avisará que há um arquivo que não está sendo controlado. Para incluir esse arquivo, digite git add newfile, depois git commit para efetivar as mudanças. Isso abrirá um editor de texto para a mensa-gem de efetivação; para evitar essa etapa, use git commit -m “Message”, que adicionará a mensagem direta-mente. Ela será gravada no arquivo de log, e é interessante usar esta mensagem como uma alteração, caso seja preciso voltar a mudança mais tarde.
Para adicionar vários arquivos a um diretório e depois efetivá-los, digite: git add .
git commit -m "Message"
Agora, experimente editar algum desses arquivos, e depois digite git status novamente; veja que o arquivo editado estará listado como Changed
but not updated (Alterado, mas não
atualizado).
Diferente de outros sistemas, o Git não adicionará uma edição a menos que seja explicitamente instruído a fazer isso. Para adicionar qualquer arquivo já controlado que tenha sido alterado, use git add filename, git commit ou git commit -a. No entan-to, isso não adicionará um arquivo
que não esteja sendo controlado (isso precisa ser feito explicitamente com git add).
Como alternativa, é possível ex-cluir seu arquivo de teste com git rm newfile.txt e depois digitar git commit. Caso o arquivo tenha sido editado desde a última inclusão, um aviso será exibido; para continuar com a exclusão, use git rm -f newfile.txt. Quando digitar git status, o sta-tus de todos os arquivos do diretó-rio aparecerá, o que significa que é possível adicionar qualquer arquivo que não tenha sido adicionado an-teriormente. No entanto, é possível que alguns arquivos nunca precisem ser adicionados (arquivos de backup ou temporários), isso implica que a saída do git status estará cheia destes arquivos. Por causa desses arquivos, não é possível usar git add para adicionar todos os arquivos ainda não incluídos, o que atrasaria seu fluxo de trabalho. A solução é criar um arquivo de texto .gitig-nore no diretório de trabalho atual com uma lista dos arquivos que não precisam ser controlados ou monitorados pelo Git. Um exem-plo do arquivo .gitignore pode se parecer com isso:
.*.sw* tmp images
Com essa configuração, arquivos com nomes como .myfile.swp (ar-quivos temporários do Vim usam esses nomes) serão ignorados, assim como tudo que estiver nos diretório
/tmp ou /images.
Se, após os testes, for interessante parar o gerenciamento desse diretó-rio com controle de fonte (assim ele não será mais um repositório Git), simplesmente remova o diretório .git com rm -rf .git.
Se digitar agora git status será informado que esse diretório não é um repositório Git. Repare que essa facilidade de remoção exige um back up do seu repositório.
Configuração do Git
Nesse ponto, uma mensagem de avi-so poderá aparecer avi-sobre seu nome e endereço de email. Todas as inclusões no Git possuem o nome e o endere-ço de email de quem fez a inclusão. O Git se esforça ao máximo para obter informações da sua máquina e resolver esses valores, mas normal-mente haverá erros. Para corrigir a informação e se livrar da mensagem de aviso, configure seu nome e ende-reço de email manualmente: git config --global user.name
Juliet Kemp
git config --global user.email juliet@earth.li
Figura 2 Saída com cores do “git status” e do “git branch”. O número de linhas no meio é a saída do status.
Obviamente, se seu repositório for privado, isso não fará diferença. No entanto, há duas boas razões para corrigir essas entradas. Em primeiro lugar, eliminará a mensagem des-necessária; em segundo lugar, essas propriedades são configuradas glo-balmente. Isso quer dizer que, uma vez determinadas, elas serão usadas em todos os outros repositórios Git, como este usuário, nesta máquina. Portanto, se estiver colaborando com outros projetos que utilizam o Git, esse será o nome de usuário e o email padrão que identificarão suas inclusões. Isso pode ser sobrescrito com base em repositórios, como na
listagem 1. Várias outras configura-ções estão disponíveis. Por exemplo, é possível fazer o Git usar cores em seus diffs (comando para compara-ção de arquivos e diretórios), status e saídas de variações (figura 2): git config --global color.diff
auto
git config --global color.status auto
git config --global color.branch auto
O manual do usuário [4] ou o tutorial do Git [5] possuem mais informações sobre opções de con-figuração que podem ser utilizadas.
Uso do Git com um
repositório externo
Até agora, vimos o uso do Git em projetos privados, novos ou já exis-tentes. Entretanto, caso se envolva em um projeto de código já existen-te que utiliza o Git, será necessário importar o código base já existente de um repositório externo. Por ser distribuído, o Git pode importar o repositório de um projeto qualquer que seja quando o acesso é permitido. No entanto, a maioria dos projetos possui, por motivos de conveniência e facilidade de se fazer versões, um repositório central que possibilita im-portações e funciona como a versão master do projeto.
Importar um projeto já existente é tão simples quanto criar seu próprio repositório. Para baixar a árvore do kernel do Linux, por exemplo, use o seguinte:
git clone git://git.kernel.org /pub/scm/linux/kernel/git/torvalds /linux-2.6.git linux-2.6
(Aviso: essa árvore é muito gran-de e seu processamento gran-demorará um pouco).
Outros projetos Linux que uti-lizam o Git incluem o GIMP, o
Debian, One Laptop Per Child e o
Perl (veja a página do Git na
Wi-kipedia para uma lista completa); seus sites irão direcioná-lo para seus repositórios centrais.
Assim que obtiver uma cópia do repositório do projeto em sua má-quina local, já é possível começar a trabalhar o código. Criar uma va-riação para suas mudanças é uma boa prática, e é possível usar o git pull para atualizar o repositório do qual você originalmente clonou o código. Mais tarde, será possível gerar um patch de suas alterações para enviar ao projeto para revisão e inclusão. Variação, atualização e
patching são discutidos em detalhes
mais adiante.
Investigar seu
histórico de revisão
Como todos os sistemas de controle de versão, o Git mantém um histó-rico de revisão do projeto, gravando tudo que foi feito em cada inclusão. Isso significa que é possível com-parar versões diferentes, conferir ações passadas e reverter para ver-sões anteriores.
Vários comandos estão disponí-veis para uso durante um exame do histórico de revisão de um projeto. O comando git show mostra os de-talhes das inclusões mais recentes. Informará o ID da revisão, o autor, a data, a mensagem de inclusão e depois uma diferenciação das mu-danças (listagem 2).
O comando git log mostra pe-quenas linhas de informações sobre cada inclusão no histórico de revisão. Para controlar quais informações serão mostradas, confira as opções na página do manual. O comando
git log filename pode ser bem útil, pois mostrará apenas as inclusões referentes ao filename. Além disso, é possível obter uma saída de apenas uma linha com git log pretty=oneline
(outras opções são short, medium,
As inclusões possuem longos IDs alfanuméricos (linha 1 da listagem 2) que são o resultado de um interes-sante recurso de segurança do Git. O nome de cada inclusão é um hash calculado usando-se o conteúdo da própria inclusão, o que significa que o histórico está garantido (não é pos-sível alterar o conteúdo da inclusão sem modificar seu nome) e o nome será globalmente único. No entanto, caso esteja trabalhando com outras pessoas, todos saberão que você está se referindo à mesma inclusão em todos os seus repositórios. Isso pode deixar os números da revisão um tanto estranhos para o trabalho, mas o Git irá auto completar o nome da revisão depois de inseridos os pri-meiros caracteres, ou então, basta copiar e colar.
O comando git diff mostra di-ferenças entre a última versão inse-rida e sua versão corrente. Para ver as diferenças entre duas inclusões prévias, use git diff commitID1 com-mitID2. Para reverter (ou cancelar) uma inclusão, use git revert com-mitID. Ou, para retornar toda sua árvore para a versão anterior, use git checkout (aviso: isso irá sobrescrever todas as suas mudanças).
Variação e união
O Git é muito flexível, e as possi-bilidades de variação e união são praticamente infinitas. A variação (criação de múltiplas “cópias” do mesmo repositório) significa que é possível separar um conjunto de mudanças para testá-las ou criar di-ferentes versões de um projeto sem afetar a árvore principal. A variação no Git é rápida e fácil, e a união pos-terior à árvore principal também é fácil, portanto, vale a pena fazer isso sempre que estiver começando um trabalho novo.
Os comandos básicos para a varia-ção são:
git branch para listar as variações atuais do projeto.
git branch BranchName para criar uma nova variação.
git branch -d BranchName para ex-cluir uma determinada variação. git checkout BranchName para
atualizar o diretório de trabalho corrente para refletir o BranchName. Use git checkout –b BranchName
para criar a variação enquanto a confere.
Digamos que seja preciso criar uma nova variação do projeto e ela será chamada de V1.5. A primeira coisa a se fazer é criar a nova varia-ção: git branch V1.5. Seu repositório possui agora duas variações, mas seu diretório de trabalho corrente ainda corresponde à variação principal (au-tomaticamente chamada master). Caso digite git branch, poderá ver o seguinte: todas as variações serão listadas, com um asterisco na que está em uso (figura 3).
Para ir para a nova variação e começar a trabalhar nela, digite git checkout V1.5. O comando git sta-tus mostrará agora o nome dessa va-riação com um asterisco. Faça uma alteração e a inclua normalmente; então, use git checkout master para voltar para a master. Sua mudança não estará mais visível. Volte para a variação, e lá estará ela de novo.
Para unir variações, use git mer-ge BranchName. Isso unirá a
Branch-Name de volta à variação corrente
(no diretório de trabalho corrente). Portanto, nesse exemplo, volte para a master (git checkout master), de-pois digite git merge V1.5 para unir as alterações na variação à variação master. As variações V1.5 e mas-ter são idênticas agora, mas o git status mostrará que a outra varia-ção ainda existe. Então, é possível continuar o trabalho de desenvol-vimento da V1.5.
Listagem 3: Conflitos na união indicados em um arquivo
01 test
02 <<<<<<< HEAD
03 this is the master branch
04 =======
05 this is the V1.5 branch
06 >>>>>>> V1.5
Listagem 2: Saída do git show
01 commit 351e8cf452b92ed591f19fdbd63023a68475a364
02 Author: Juliet <juliet@earth.li>
03 Date: Tue Mar 2 11:47:04 2010+0000
04 Testing delete
05 diff --git a/newfile.txtb/newfile.txt
06 deleted file mode 100644
07 index e69de29..0000000
Listagem 1: Configuração de inclusão por repositório
01 cd /home/juliet/my_anonymous_repository
02 git config user.name Someone Else
Figura 3 Criar e conferir uma nova variação (repare no nome da variação no topo da saída do status).
Repare que o Git não fará a união caso haja mudanças não incluídas, pois a união irá sobrescrever o atual diretório de trabalho (caso não esteja pronto para fazer a inclusão, é pos-sível usar git stash).
Na hora de fazer a união, se possí-vel, o Git completa automaticamen-te a inclusão. No entanto, algumas vezes há conflito de arquivos (uma mudança que afeta outra). Nesse caso, a união não será feita, gerando a informação sobre quais arquivos estão com problemas. O git status
também listará esses arquivos como não unidos. Para resolver o confli-to, abra os arquivos problemáticos em um editor de texto. As seções relevantes estarão marcadas como mostra a listagem 3.
Ambas as versões do arquivo são mostradas, e é possível escolher como o problema será resolvido. Uma vez editado o arquivo, exe-cute git add file.txt para cada arquivo problemático, depois git commit para terminar a união da inclusão. Outra maneira seria usar
git commit -a para marcar automa-ticamente todos os conflitos como resolvidos. Certifique-se de que eles
foram mesmo resolvidos antes de fazer isso.
Trabalhar com patches
Caso esteja trabalhando com outras pessoas, há algumas maneiras de compartilhar suas alterações com elas. Uma das opções é que elas importem ou unam-se diretamente à sua árvore. No entanto, a aborda-gem mais comum é gerar um patch (um arquivo texto descrevendo suas alterações à árvore do projeto) e compartilhá-lo por email. Feliz-mente, o sistema de patching do Git facilita isso.
Antes mesmo de começar a fazer suas mudanças, é interessante criar uma variação para armazená-las – por exemplo, com git checkout -b MyBugFix. Agora, o trabalho será feito na variação MyBugFix (veja o comando git stash caso tenha começado a trabalhar na variação
master).
Depois que suas mudanças fo-rem feitas e incluídas, certifique-se que certifique-seu repositório local está atualizado com o resto do projeto. Volte para a variação master com
git checkout master, use git pull
para atualizá-la com o repositório no qual originalmente foi clona-do o código base. Agora, volte à variação com git checkout MyBu-gFix e digite git rebase master. Isso aplicará todas as mudanças ocorri-das na variação master à variação
MyBugFix. Isso também atualiza
o histórico para que sua variação se origine da versão mais recente da variação master. Logicamente, conflitos precisarão ser resolvidos, caso existam.
Agora, tudo está pronto para a criação do patch:
git format-patch master --stdout > mybugfix-patch.diff
Isso compara a variação do traba-lho corrente (no caso, MyBugFix) com a variação master e encontra as inclusões que não ocorreram na variação master. Isso gera um patch por inclusão na saída padrão e o di-recionamento destes para o arquivo
mybugfix-patch.diff. Além disso,
também é possível usar git for-mat -patch master -o patchdir para salvá-los no diretório de patches. Os patches são todos formatados como emails.
Para aplicar o patch de outra pessoa, é possível usar git am. Mais uma vez, crie uma nova variação com git checkout -b JhonsPatch, para não confundir o patch com as alterações (é fácil criar e unir varia-ções com o Git, portanto, use-as!). Digite então, git am jhonspatchfile. diff para unir a mudança para que se possa examiná-la. Com projetos gerenciados externamente, não é uma boa ideia unir as mudanças na variação master até que elas sejam centralmente aceitas (ao receber a atualização na próxima vez que usar git pull). Mas, se o projeto for pequeno, apenas você e o Jhon trabalhando nele, e se você está satisfeito com o patch, é possível unir a variação à variação master
Figura 4 A janela gitk mostrando um histórico de revisão, variações e diffs.
com git checkout master; git merge JhonsPatch.
Repare que git am também usa arquivos de patch que chegaram por email. Basta descartar todos os patches na caixa de correio (no formato padrão Linux mailbox), e executar git am mailboxfile para aplicar todos os patches que estão na caixa do correio à variação cor-rente. Usando a linha From: de cada mensagem para o nome do autor da inclusão, a linha Date: para a hora e a Subject: para o título da inclusão. A mensagem de inclusão será a linha Subject: mais o corpo da mensagem (até o começo do patch). Esse formato é usado para salvar com git format-patch.
Guardando
as mudanças
Outra ferramenta útil para gerar patches ou trabalhar em projetos complexos é git stash, projetado para aqueles momentos em que é preciso misturar suas alterações fora de sua árvore existente, mas sem perdê-las (portanto, não basta voltar para a
inclusão anterior) ou mudar para outra variação.
Para salvar todas as alterações no “esconderijo” (stash) e voltar para o estado da última inclusão no pro-jeto, use: git stash save “work on project foo”.
Faça uma pequena correção e a inclua normalmente, depois use git stash pop para guardar suas mudan-ças salvas.
O comando git stash pode ser útil caso se esteja no meio de uma grande alteração e, de repente, um pequeno erro for localizado. Para salvar as alterações, corrigir esse erro, fazer a inclusão e gerar um patch use git stash save “work on Big $Thing”, e depois use git stash pop para retornar as alterações salvas para a árvore. Como você pode ver,
git stash e git branch se sobrepõe – basta enxergar a funcionalidade stash como um tipo de branch mais leve.
Se perceber que estava trabalhan-do na variação errada, é possível utilizar git stash. Nesse caso, salve as alterações no esconderijo, mude de variação e traga as alterações do esconderijo para a nova variação.
Tagging com o Git
O comando git tag permite atribuir
tags, ou rótulos, a uma inclusão
par-ticular. Tags são mais usadas para marcar pontos de lançamento, mas é possível usá-las para o que for ne-cessário. Para ver a lista de tags, em ordem alfabética, no seu diretório de trabalho corrente, basta digitar git tag. Para procurar padrões específi-cos, tente git tag V1.* para as tags que principiam por V1..
Para adicionar suas próprias tags ao ponto corrente, use git tag -a: git tag -a "April" -m "Start of
April"
Esse comando atribui uma tag à inclusão mais recente com o nome “April”, e a mensagem da tag será “Start of April” (sem a utilização do -m, um editor de texto se abrirá para que a mensagem seja digita-da). Digitar git tag agora mostrará a informação da tag e os detalhes da inclusão mais recente.
Se houver uma chave privada GPG, é possível usá-la para assinar a tag. Basta usar -s TagName em vez
Mais informações
[1] Site oficial do Git: http://git-.com
[2] Email de Linus Torvalds falando sobre as vantagens de
um sistema distribuído: http://lwn.net/Articles/246381/
[3] Download do Git: http://www.kernel.org/pub/software/scm/git
[4] Manual do usuário Git:
http://www.kernel.org/pub/software/scm/git/docs/user-.html
[5] Tutorial oficial do Git:
http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html
[6] Curso básico Subversion-to-Git: http://git-.com/course/svn.html
Gostou do artigo?
Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br
Este artigo no nosso site: http://lnm.com.br/article/3571
Sobre o autor
Juliet Kemp é administradora de sistemas há quase uma década e é a autora de Linux
Sys-tems Administration Recipes (Apress). Ela é fã de controles de versão e, recentemente, con-verteu-se ao Git.
de -a TagName, e a senha de sua cha-ve será solicitada. Para cha-verificar uma assinatura em uma tag, use git tag -v TagName.
Além disso, é possível criar uma tag mais leve com git tag April, que não tenha uma mensagem nem uma assinatura GPG. O comando git show April mostrará, então, apenas as informações sobre a inclusão, sem informações sobre a tag. Isso pode ser útil se uma referência rápida for suficiente para uma inclusão deter-minada, e não uma marcação mais informativa e longa.
Por fim, é possível atribuir uma tag a uma inclusão – que não a mais recente – especificando-se o início do ID da inclusão. Para achar o ID, digite git log, e use:
git tag -a March -m "Start of March" ad829ce
para atribuir uma tag à inclusão cujo ID inicie com “ad829ce”.
Outras coisas
interessantes
Neste artigo, mostramos recursos básicos do Git para que ele possa ser usado em seus próprios projetos ou participar de um projeto maior que adote-o. Há muito mais a disposição. Todos os comandos já mencionados são muito flexíveis, e uma grande variedade de opções está disponível para todos eles – confira man git – [tool] (experimente usar man git -add para mais informações). Todos os exemplos aqui citados funciona-ram com a inclusão ou conjunto de inclusões mais recentes, mas muitos comandos utilizam os IDs das inclusões.
Outros recursos que podem ser investigados incluem:
Instale o pacote gitk para a fer-ramenta gitk, que mostra uma revisão visual do histórico do seu projeto (figura 4).
O Git, como outros sistemas de controle de versão, suporta hook
scripts. Isso permite a
configu-ração de scripts para que sejam executados antes ou depois de determinados eventos. Por exem-plo, é possível fazer um teste de unidade antes da inclusão, procurar por espaços em bran-co ou enviar um email após um evento. Confira .git/hooks/ em seu diretório de trabalho para obter alguns exemplos (remova a extensão .sample desses scripts para executá-los) ou escreva seus próprios scripts.
Ferramentas estão disponíveis para interação com outro sis-tema de controle de versão. O git -svn possibilita o uso do Git com um repositório Subversion [6].
Saiba que, diferente de um siste-ma centralizado, o Git não oferece nenhuma solução do tipo “Backup Lite”: caso o diretório de trabalho seja excluído sem querer, seu histó-rico de revisão também será perdi-do (porém, não se deve confiar no Backup Lite – faça backups de seus dados correta e regularmente). Em um projeto distribuído, no entanto, outros terão o histórico salvo.
Conclusão
O Git é rápido, fácil de usar e muito flexível. Se estiver trabalhando em um projeto altamente distribuído sem um repositório central definiti-vo, publique apenas versões estáveis que possam ser tratadas como uma variação ou uma tag particular. Isso é bom não só para grupos, mas também para seus trabalhos particulares. n
