Git no Controle. Com softwares de controle de

Transcrição

1 Controle de versão flexível, poderoso e fácil TUTORIAL 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 Jasmin Merdan, 123RF Com 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 variações do seu trabalho. Projetos de software invariavelmente usam alguma 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 flexibilidade, velocidade e estrutura altamente distribuída popularizaram o uso em todos os tipos de projetos. O Git é projetado para ser altamente 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 suportar desenvolvimento não linear: ele espera que mudanças sejam unidas repetidamente conforme vão sendo passadas por revisores e desenvolvedores 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 desenvolvimento 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 instalado, é fácil configurar seu primeiro repositório. A natureza distribuída do Git significa que cada cópia do 60

2 Git TUTORIAL trabalho contém seu próprio repositório (no subdiretó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 é extremamente 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 mensagem 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 mensagem de efetivação; para evitar essa etapa, use git commit -m Message, que adicionará a mensagem diretamente. 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" que não esteja sendo controlado (isso precisa ser feito explicitamente com git add). Como alternativa, é possível excluir 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 status de todos os arquivos do diretório aparecerá, o que significa que é possível adicionar qualquer arquivo que não tenha sido adicionado anteriormente. 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.gitignore no diretório de trabalho atual com uma lista dos arquivos que não precisam ser controlados ou monitorados pelo Git. Um exemplo do arquivo.gitignore pode se parecer com isso:.*.sw* tmp images Com essa configuração, arquivos com nomes como.myfile.swp (arquivos 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 aviso poderá aparecer sobre seu nome e endereço de . Todas as inclusões no Git possuem o nome e o endereço de 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 normalmente haverá erros. Para corrigir a informação e se livrar da mensagem de aviso, configure seu nome e endereço de manualmente: git config global user.name Juliet Kemp git config global user. juliet@earth.li 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 entanto, isso não adicionará um arquivo Figura 1 Configurar um diretório como repositório Git é simples, através da linha de comando. Linux Magazine #68 Julho de

3 TUTORIAL Git 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 desnecessária; em segundo lugar, essas propriedades são configuradas globalmente. 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 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 configuraçã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á existentes. Entretanto, caso se envolva em um projeto de código já existente 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 importaçõ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 grande e seu processamento demorará um pouco). Outros projetos Linux que utilizam o Git incluem o GIMP, o Debian, One Laptop Per Child e o 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. Perl (veja a página do Git na Wikipedia 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 variaçã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 comparar versões diferentes, conferir ações passadas e reverter para versõ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 detalhes 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 mudanças (listagem 2). O comando git log mostra pequenas 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, full, fuller, e raw). 62

4 Git TUTORIAL As inclusões possuem longos IDs alfanuméricos (linha 1 da listagem 2) que são o resultado de um interessante 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 é possí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 primeiros caracteres, ou então, basta copiar e colar. O comando git diff mostra diferenças entre a última versão inserida e sua versão corrente. Para ver as diferenças entre duas inclusões prévias, use git diff commitid1 commitid2. Para reverter (ou cancelar) uma inclusão, use git revert commitid. 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 possibilidades 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 diferentes versões de um projeto sem afetar a árvore principal. A variação no Git é rápida e fácil, e a união posterior à á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 excluir 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 (automaticamente 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 status mostrará agora o nome dessa variaçã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 merge 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), depois digite git merge V1.5 para unir as alterações na variação à variação master. As variações V1.5 e master 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 desenvolvimento da V1.5. Listagem 1: Configuração de inclusão por repositório 01 cd /home/juliet/my_anonymous_repository 02 git config user.name Someone Else 03 git config user. someone.else@gmail.com Listagem 2: Saída do git show 01 commit 351e8cf452b92ed591f19fdbd63023a68475a Author: Juliet <juliet@earth.li> 03 Date: Tue Mar 2 11:47: Testing delete 05 diff git a/newfile.txtb/newfile.txt 06 deleted file mode index e69de 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 Linux Magazine #68 Julho de

5 TUTORIAL Git 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, é possível usar git stash). Na hora de fazer a união, se possível, o Git completa automaticamente 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 conflito, 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, execute 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 automaticamente 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 abordagem mais comum é gerar um patch (um arquivo texto descrevendo suas alterações à árvore do projeto) e compartilhá-lo por . Felizmente, 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 forem feitas e incluídas, certifiquese que seu repositório local está atualizado com o resto do projeto. Volte para a variação master com git checkout master, use git pull Figura 3 Criar e conferir uma nova variação (repare no nome da variação no topo da saída do status). para atualizá-la com o repositório no qual originalmente foi clonado o código base. Agora, volte à variação com git checkout MyBugFix e digite git rebase master. Isso aplicará todas as mudanças ocorridas 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 trabalho 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 direcionamento destes para o arquivo mybugfix-patch.diff. Além disso, também é possível usar git format -patch master -o patchdir para salvá-los no diretório de patches. Os patches são todos formatados como s. 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 64

6 Git TUTORIAL 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 . 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 corrente. 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 projeto, 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 trabalhando 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 particular. Tags são mais usadas para marcar pontos de lançamento, mas é possível usá-las para o que for necessá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íficos, 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 digitada). 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 Linux Magazine #68 Julho de

7 TUTORIAL Git de -a TagName, e a senha de sua chave será solicitada. Para 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 determinada, 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 O Git, como outros sistemas de controle de versão, suporta hook scripts. Isso permite a configuração de scripts para que sejam executados antes ou depois de determinados eventos. Por exemplo, é possível fazer um teste de unidade antes da inclusão, procurar por espaços em branco ou enviar um 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 sistema de controle de versão. O git -svn possibilita o uso do Git com um repositório Subversion [6]. Saiba que, diferente de um sistema 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á perdido (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 definitivo, 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 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 funcionaram 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 ferramenta gitk, que mostra uma revisão visual do histórico do seu projeto (figura 4). Mais informações [1] Site oficial do Git: [2] de Linus Torvalds falando sobre as vantagens de um sistema distribuído: [3] Download do Git: [4] Manual do usuário Git: [5] Tutorial oficial do Git: [6] Curso básico Subversion-to-Git: Sobre o autor Juliet Kemp é administradora de sistemas há quase uma década e é a autora de Linux Systems Administration Recipes (Apress). Ela é fã de controles de versão e, recentemente, converteu-se ao Git. Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em cartas@linuxmagazine.com.br Este artigo no nosso site: