Apostila Git Hachi Tecnologia

GIT - Controle de Verso com Rapidez e Segurana
Autor: Lucas Medeiros de Freitas Verso 1.12.4.6
2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br
ndice
1 - Sistema de Controle de Verso, uma breve explicao!
1.1 Controle de Verso! 1.1.1. O que e por que us-lo?! 1.1.2. Como funciona?! 1.2. Sistema de Controle de Verso Centralizado! 1.3. Sistema de Controle de Verso Distribudo!
1 1 1 1 2 5 9 9 9 10 10 11 11 12 12 12 14 14 14 14
i
2 - Introduo ao Git!
2.1. Git, um SCM rpido e seguro! 2.2. Projetos que usam o Git ! 2.3. Com o Git, tudo local ! 2.4. O Git rpido! 2.5. O Git facilmente adaptvel ao seu uxo de trabalho! 2.6. rea intermediria !
3 - Iniciando com o Git!

3.1. Instalando o Git! 3.1.1. Instalando o Git no Mac! 3.1.2. Instalando o Git no Linux! 3.1.2.1 Instalando o Git em distribuies que usam o YUM ! 3.1.2.2 Instalando o Git em distribuies que usam o APT-GET ! 3.1.2.3 Instalando o Git a partir do source !
2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!
3.1.3. Instalando o Git no Windows ! 3.2. Congurando o Git ! 3.2.1. Exerccio ! 3.3. Criando um repositrio com o Git ! 3.3.1. Exerccio ! 3.4. Realizando nosso primeiro commit ! 3.4.1. Exerccio !
14 17 17 17 18 18 20 22 22 22 24 26 27 27 27 28 30 30 31 33 33 34 34 34 34
ii
4 - Trabalhando em Equipe!
4.1. Hospedando nosso projeto no GitHub! 4.1.1. Criando uma conta de usurio no GitHub ! 4.1.2. Criando um repositrio no GitHub! 4.1.3. Enviando nossas alteraes ao repositrio do GitHub! 4.1.4. Exerccio ! 4.2. Colaborando com o projeto! 4.2.1. Adicionando um colaborador ao repositrio do GitHub! 4.2.2. Realizando um clone do repositrio remoto ! 4.2.3. Enviando as alteraes ao repositrio remoto! 4.2.4. Baixando as atualizaes do repositrio remoto! 4.2.5. Resoluo manual de conitos ! 4.2.6. Git blame, o famoso dedo-duro ! 4.2.7. Exerccio !
5 - Recursos avanados do Git!

5.1. Trabalhando com branches ! 5.1.1. Criando uma branch ! 5.1.2. Alternando entre branches !
5.1.3. Trabalhando com a nova branch! 5.1.4. Enviando as alteraes para a branch master! 5.1.5. Resolvendo conitos no rebase! 5.1.6. Enviando uma branch local para o repositrio remoto ! 5.1.7. Baixando uma branch do repositrio remoto para o repositrio local! 5.1.8. Exerccio ! 5.2. Etiquetando nosso cdigo com tags ! 5.2.1. Criando uma tag ! 5.2.2. Exerccio ! 5.3. Usar o di" faz toda a diferena! 5.3.1. Mostrando as alteraes realizadas no working directory! 5.3.2. Mostrando a diferena entre dois commits ! 5.3.3. Mostrando a diferena entre o commit atual e commits anteriores ! 5.3.4. Exerccio ! 5.4. Desfazendo alteraes ! 5.4.1. Descartando alteraes no working directory! 5.4.1.1. Exerccio ! 5.4.2. Descartando alteraes no Index! 5.4.2.1. Exerccio ! 5.4.3. Descartando alteraes do ltimo commit! 5.4.3.1. Exerccio ! 5.4.4. Descartando alteraes de um commit antigo! 5.4.4.1. Exerccio ! 5.5. Procurando bugs em commits antigos ! 5.5.1. Exerccio !
35 39 40 44 45 45 47 47 48 49 49 49 50 50 50 51 52 52 53 53 54 54 55 56 58
iii
5.6. Guardando alteraes para depois ! 5.6.1. Exerccio !
59 60 61 61 61 62 62 63 64 64 65 67 67 67 68
6 - Ferramentas grcas do Git!

6.1. Ferramentas grcas para Mac! 6.1.1. GitX! 6.1.2. SmartGit! 6.1.3. Tower! 6.2. Ferramentas grcas para Linux! 6.2.1. Git Cola ! 6.2.2. GitK ! 6.3. Ferramenta grca para Windows !
7 - Apndice!
7.1. Montando um repositrio centralizado! 7.1.1. Montando um repositrio centralizado no Mac e Linux! 7.1.2. Montando um repositrio centralizado no Windows !
iv
1 - Sistema de Controle de Verso, uma breve explicao
1.1 Controle de Verso

1.1.1. O que e por que us-lo?
Sistema de Controle de Verso, SCM (Source Code Management) ou VCS (Version Control System), um sistema que registra alteraes em um arquivo, ou em um conjunto de arquivos, ao longo do tempo, de forma que possamos voltar a uma verso especca mais tarde. Embora seja mais usado para arquivos de cdigo fonte de software, o Sistema de Controle de Verso pode ser usado para quase qualquer tipo de arquivo de computador. O Sistema de Controle de Verso permite a um programador, por exemplo: Reverter seu cdigo fonte a uma verso anterior; Comparar as alteraes do cdigo fonte ao longo do tempo; Manter um histrico de evoluo do seu projeto; Saber quando e quem fez as alteraes nos arquivos de cdigo fonte; Procurar por um bug inserido no cdigo fonte em um determinado perodo; Identicar as alteraes feitas nos arquivos do projeto; Trabalhar em equipe de forma simples e prtica; Criar ramicaes do projeto com facilidade; Recuperar todos os arquivos do projeto em caso de perda dos arquivos por acidente.
1.1.2. Como funciona?

Os Sistemas de Controle de Verso trabalham de forma semelhante, possuindo um repositrio para armazenar os arquivos e todo o histrico de evoluo do projeto, e uma rea de trabalho que nos permite trabalhar diretamente com os arquivos fazendo as alteraes necessrias. O repositrio como se fosse um banco de dados, que guarda todas as revises do projeto, ou seja, todas as alteraes feitas em seus arquivos bem como todo o histrico de evoluo do projeto: quem fez, quando fez e o que fez. A rea de trabalho existe justamente para no trabalharmos diretamente nos arquivos armazenados no repositrio, provendo uma cpia dos arquivos do projeto onde podemos alter-los de forma segura, e estes so monitorados pelo SCM. A Figura 1 ilustra a comunicao entre a rea de trabalho e o repositrio de um SCM.
Figura 1. Funcionamento de um SCM. Fonte: Pronus Engenharia de Software
Em um esquema lgico, um desenvolvedor realiza as alteraes nos arquivos de cdigo fonte diretamente na rea de trabalho e, quando estas alteraes esto maduras o suciente, o desenvolvedor envia tais alteraes para o repositrio, criando assim uma nova reviso.
Figura 2. Esquema geral lgico de um SCM. Fonte: Wikipdia
Cada reviso armazenada no repositrio contm a parte sinttica do projeto, ou seja, as alteraes realizadas nos arquivos, e o histrico dessa reviso, com informaes de quem fez tais alteraes, quando foram feitas e o que foi feito. Existem basicamente dois tipos de Sistemas de Controle de Verso: os centralizados e os distribudos. Veremos nos prximos tpicos as diferenas entre os dois.
1.2. Sistema de Controle de Verso Centralizado

Um SCM centralizado trabalha de forma dependente de um servidor central. Neste modelo cada integrante de uma equipe de desenvolvedores tem sua prpria rea de trabalho em seu computador pessoal e o repositrio ca armazenado em um servidor central. A sincronizao entre o repositrio e a rea de trabalho s possvel quando se est conectado rede e tem-se acesso a este servidor. Neste modelo toda a comunicao feita atravs do repositrio central, onde so realizados os commits e updates.
GIT - Controle de Verso com Rapidez e Segurana A Figura 3 mostra o funcionamento de um SCM centralizado, ilustrando uma equipe de trs desenvolvedores (Aline, Roberto e Andr) trabalhando em suas alteraes, localmente em seus computadores, na rea de trabalho, e sincronizando essas alteraes com o repositrio central atravs da rede. Cada desenvolvedor pode enviar suas alteraes para o repositrio central atravs de um commit e baixar todas as atualizaes feitas por outros desenvolvedores atravs de um update.
Figura 3. Funcionamento de um SCM centralizado. Fonte: Pronus Engenharia de Software
Para obter uma cpia do projeto em um SCM centralizado, os desenvolvedores precisam realizar um checkout, como ilustra a Figura 4. Neste exemplo, os desenvolvedores Aline e roberto obtm uma cpia do projeto e partem do mesmo ponto.
Figura 4. Desenvolvedores obtendo uma cpia do projeto atrves de um checkout no repositrio central. Fonte: Pronus Engenharia de Software
Aps obterem uma cpia do projeto, Aline e Roberto trabalham em suas alteraes. Ento Aline naliza suas alterae e as envia ao repositrio central atravs de um commit, como ilustra a Figura 5.
Figura 5. Ambos os desenvolvedores trabalham em modicaes no projeto, mas Aline publica suas alteraes primeiro. Fonte: Pronus Engenharia de Software
Quando Roberto tenta enviar suas modicaes, o servidor as recusa e informa que seus arquivos esto desatualizados, como ilustra a Figura 6.
Figura 6. Roberto envia suas modicaes logo aps Aline ter feito um commit, e ento o servidor recusa suas modicaes. Fonte: Pronus Engenharia de Software
Roberto precisa atualizar seu cdigo para receber as atualizaes de Aline, atravs de um update. Desta forma as atualizaes de Aline so mescladas com o cdigo que est em sua rea de trabalho. Este processo de mesclagem conhecido como merge.
Figura 7. Roberto realiza um update para receber as atualizaes de Aline. Fonte: Pronus Engenharia de Software
GIT - Controle de Verso com Rapidez e Segurana Aps realizar o update, Roberto obtm as novas atualizaes do repositrio central. Agora Roberto poder enviar as suas modicaes normalmente atravs de um commit.
Figura 8. Aps ter feito um update, Roberto estar apto a enviar suas modicaes atravs de um commit. Fonte: Pronus Engenharia de Software
Enquanto Roberto est atualizando seu cdigo e enviando suas alteraes para o repositrio central, Aline trabalha em novas modicaes no projeto, podendo envi-las normalmente, caso no tenha alterado o mesmo arquivo que Roberto.
Figura 9. Aline envia suas alteraes normalmente ao repositrio central, j que estas no foram feitas no mesmo arquivo que Roberto modicou. Fonte: Pronus Engenharia de Software
1.3. Sistema de Controle de Verso Distribudo

Em um SCM distribudo no existe repositrio central. Cada desenvolvedor possui um repositrio indepentente em seu computador local e uma rea de trabalho para trabalhar diretamente nos arquivos. Desta forma todo o trabalho feito localmente, no dependendo da rede para realizar commits e updates. Como um SCM distribudo no depende da rede e todo o trabalho feito localmente, o processo de sincronizao com o repositrio muito mais rpido, pois no teremos que enfrentar os problemas de latncia de rede, j que teremos um repositrio em nosso sistema de arquivos local. Esta uma grande vantagem dos SCMs distribudos, pois podemos trabalhar desconectados. Imagine a comodidade e a praticidade de poder trabalhar em seu projeto e controlar sua verso enquanto est viajando em um avio, ou em um local que no possui acesso rede. Isto aumenta muito a produtividade e a praticidade ao se trabalhar em um projeto versionado. A Figura 10 ilustra o funcionamento de um SCM distribudo.
Figura 10. Funcionamento de um SCM distribudo. Neste modelo cada desenvolvedor possui um repositrio independente e uma rea de trabalho. Fonte: Pronus Engenharia de Software
Mesmo sendo local o repositrio em um SCM distribudo, podemos sincronizar facilmente com outros repositrios remotos na rede atravs dos comandos pull e push.
Figura 11. Podemos sincronizar nosso repositrio com o de outros desenvolvedores em um SCM distribudo, ou at mesmo simular um repositrio central. Fonte: Pronus Engenharia de Software
Seguindo nosso exemplo, mas agora trabalhando em um SCM distribudo, o desenvolvedor Roberto realiza um clone do repositrio de Aline e, a partir de ento, ambos partem do mesmo ponto.
Figura 12. Roberto realiza um clone do repositorio de Aline, obtendo uma copia el de todo o contedo sintrico e todo o histrico do projeto. Fonte: Pronus Engenharia de Software
GIT - Controle de Verso com Rapidez e Segurana Aline e Roberto podero trabalhar normalmente em seus repositrios locais, sem interferir no repositrio um do outro.
Figura 13. Aline e Roberto trabalham em novas modicaes em seus repositrios locais, sem interferir no repositrio um do outro. Fonte: Pronus Engenharia de Software
Mesmo possuindo um repositrio local, Roberto poder sincronizar seu repositrio com o de Aline, obtendo todas as modicaes realizadas por ela, atravs de um comando pull.
Figura 14. Roberto baixa as atualizaes feitas por Aline, atravs de um comando pull. Fonte: Pronus Engenharia de Software
Ao baixar as atualizaes de Aline, estas sero mescladas no repositrio local de Roberto atravs de um merge.
Figura 15. Um merge feito no repositrio local de Roberto, aps baixar as atualizaes do repositrio da Aline. Fonte: Pronus Engenharia de Software
Depois de ter baixado as atualizaes de Aline, Roberto publica suas modicaes em seu repositrio local. Enquanto isso, Aline trabalha normalmente e publica novas alteraes no repositrio local dela.
Figura 16. Aline e Roberto publicam alteraes em seus repositrios locais. Fonte: Pronus Engenharia de Software
GIT - Controle de Verso com Rapidez e Segurana Finalmente Roberto envia suas atualizaes para o repositrio local de Aline atravs do comando push, mesclando suas atualizaes no repositrio local dela. Aline agora possuir todas as alteraes feitas por ela e por Roberto, bem como todo o histrico de alteraes efetuadas por eles.
Figura 17. Roberto envia suas alteraes para o repositrio local de Aline, atravs de um push. Fonte: Pronus Engenharia de Software
Como vimos, o Sistema de Controle de Verso distribudo tem uma vantagem muito grande por trabalhar desconectado, sem a necessidade de um servidor central. O Git um SCM distribudo e iremos aprender mais sobre ele nos prximos tpicos.
2 - Introduo ao Git
2.1. Git, um SCM rpido e seguro

O Git um SCM open source distribudo, moderno e poderoso, e vem sendo utilizado cada vez mais em grandes projetos no mundo inteiro. O Git um SCM muito rpido, foi criado por Linus Torvalds (pai do Linux e mantenedor do Kernel do Linux) e inicialmente foi projetado para trabalhar com o versionamento do Kernel do Linux, ou seja, desde seu princpio o Git j trabalha bem com sistemas muito grandes. O Git surgiu a partir da necessidade de se ter um SCM capaz de acompanhar a velocidade com que o Kernel do Linux desenvolvido. Antes do Git, o Kernel do Linux era versionado pelo BitKeeper, um SCM tambm distribudo porm comercial (pago) e, mesmo sendo um tanto rpido, o BitKeeper no era rpido o suciente para acompanhar a velocidade com que o Kernel do Linux sofria alteraes em seu cdigo. Centenas de programadores contribuem com o Kernel do Linux no mundo inteiro e muitas alteraes so feitas todos os dias, sendo assim apenas um SCM distribudo muito rpido para atender a este cenrio. A partir desta necessidade, Linus Torvalds criou um SCM distribudo, chamado Git, que se demonstrou to rpido que ganhou a ateno de muitos desenvolvedores e se tornou o SCM ocial do Kernel do Linux. Hoje o Git mantido por Junio Hamano, responsvel pela evoluo deste incrvel SCM. Para quem est acostumado com SCMs centralizados, como o CVS e o Subversion, e quer iniciar com o GIT, preciso ter em mente algumas diferenas cruciais: Primeiro, o GIT no possui um servidor central; Segundo, o GIT no possui um servidor central. Em SCMs distribudos, todos os usurios possuem um clone do repositrio original com o histrico completo do projeto, e essa a essncia dos SCMs distribudos. O GIT no possui um sistema de autenticao prprio. Isto uma vantagem, pois voc pode usar o sistema de autenticao de acordo com o protocolo que escolher ao se trabalhar com sincronizao remota de repositrios.
2.2. Projetos que usam o Git

Atualmente vrios projetos grandes e conhecidos usam o Git como SCM. Podemos citar abaixo alguns projetos importantes que usam o Git: O prprio Git; Kernel do Linux; Perl; Eclipse; Gnome; KDE;
GIT - Controle de Verso com Rapidez e Segurana Ruby; Android; PostgreSQL; Debian Linux; X.org. .. e inmeros outros. O Git trabalha bem com projetos grandes, garantindo segurana, performance e incrveis recursos para o controle de verso.
2.3. Com o Git, tudo local

Com o Git, tudo feito localmente em seu sistema de arquivos. Isso torna todo o processo de versionamento muito mais produtivo, permitindo que commits sejam feitos totalmente desconectado da rede. Imagine a praticidade de poder trabalhar em seu projeto, criar branches, fazer merges e commits e poder listar todo o histrico do seu projeto enquanto estiver em viagem, em um vo. Isso muito produtivo.
Figura 18. Todo o processo de versionamento feito localmente com o Git, podendo sincronizar com repositrios remotos apenas quando necessrio. Fonte: whygitisbetterthanx.com
2.4. O Git rpido

Em comparao com SCMs centralizados como o CVS e SVN, obviamente o Git muito mais rpido por trabalhar localmente. Mas em comparao com outros SCMs distribudos, como o Mercurial e o Bazaar, o Git tambm se demonstra muito mais rpido. Isto deve-se pelo fato de o Git ser totalmente escrito em C e seus desenvolvedores terem tido toda uma preocupao com performance desde seu incio, j que desde seu nascimento o Git j trabalhava com repositrios enormes como o do Kernel do Linux.
10
Figura 19. O Git possui um tempo de resposta muito menor em diversas tarefas, comparado com outros SCMs distribudos. Fonte: whygitisbetterthanx.com
2.5. O Git facilmente adaptvel ao seu uxo de trabalho

O Git facilmente adaptvel ao seu Fluxo de Trabalho. Se sua equipe tem a necessidade de ter um Repositrio Central, por exemplo, mesmo sendo um SCM Distribudo, possvel criar um Repositrio Central com o GIT.
Figura 20. Exemplo de um uxo de trabalho usando um repositrio central com o Git. Fonte: whygitisbetterthanx.com
2.6. rea intermediria

O Git possui uma rea intermediria (Index), onde podemos decidir o que realmente vai ser commitado. A vantagem que podemos adicionar apenas os arquivos desejados na rea intermediria e fazer o commit apenas destes arquivos, sem a necessidade de fazer o commit de tudo o que foi modicado na rea de trabalho.
Figura 21. rea intermediria do Git, uma grande vantagem em relao a outros SCMs. Fonte: whygitisbetterthanx.com
11
3 - Iniciando com o Git
3.1. Instalando o Git

O Git fcil de ser instalado e possui suporte a diversos Sistemas Operacionais. Veremos nos prximos tpicos como instalar o Git nos trs sistemas operacionais mais conhecidos: Mac OSX, Linux e Windows.
3.1.1. Instalando o Git no Mac

O Git possui um instalador para usurios Mac. Para instal-lo, basta seguir os passos abaixo: Entre no site http://code.google.com/p/git-osx-installer/downloads/list?can=3 e baixe a ltima verso do instalador do Git para Mac, de acordo com a verso do seu Sistema Operacional.
Figura 22. Selecione a ltima verso da instalao do Git para download, de acordo com a verso do seu OSX.
Figura 23. Clique no link contendo o arquivo de instalao para baixar o instalador do Git.
12
GIT - Controle de Verso com Rapidez e Segurana Aps ter feito o download do instalador, basta abr-lo para iniciar a instalao. Na tela inicial do instalador, clique em Continuar para prosseguir com a instalao.
Figura 24. Tela inicial do instalador do Git.
Clique em instalar para iniciar a instalao do Git.
Figura 25. Tela do instalador do Git.
Aps instalado, clique em Fechar para encerrar o instalador do Git.
13
GIT - Controle de Verso com Rapidez e Segurana Agora o Git est instalado e pronto para ser usado em seu Mac.
3.1.2. Instalando o Git no Linux

Instalar o Git no Linux simples. Basta usar o gerenciador de pacotes de acordo com a sua distribuio. 3.1.2.1 Instalando o Git em distribuies que usam o YUM Em distribuies do Linux que usam o YUM como gerenciador de pacotes, basta executar o seguinte comando (como root) para instalar o Git: " yum install git-core
3.1.2.2 Instalando o Git em distribuies que usam o APT-GET Em distribuies do Linux que usam o APT-GET como gerenciador de pacotes, basta executar o seguinte comando (como root) para instalar o Git: " " 3.1.2.3 Instalando o Git a partir do source Outra opo para instalar o Git no Linux a partir do source. Baixe o source do Git no link: " http://git-scm.com/download apt-get install git-core
Aps baixar o source do Git, basta descompact-lo e, em seu diretrio, executar os seguintes comandos (como root) para instalar: " ! make prex=/usr all make prex=/usr install
3.1.3. Instalando o Git no Windows

Para instalar o Git no Windows, baixe a ltima verso do msysgit no link: http://code.google.com/p/msysgit/downloads/list Ao abrir o instalador, clique em Next.
Figura 27. Tela inicial do instalador do Git.
14
GIT - Controle de Verso com Rapidez e Segurana Na tela de licena, clique em Next.
Escolha o diretrio onde o Git dever ser instalado e clique em Next.
Na tela seguinte, deixe marcadas as opes padres e clique em Next.
15
GIT - Controle de Verso com Rapidez e Segurana Na prxima tela, dena como deve aparecer o nome do Git no menu Iniciar do Windows. Deixe o padro, Git, e clique em Next.
Na prxima tela, devemos denir como devemos usar o Git no Windows. Marque a opo Run Git from de Windows Command Prompt e clique em Next, conforme imagem a seguir.
Na prxima tela, deixe marcado a primeira opo e clique em Next, conforme imagem a seguir.
16
GIT - Controle de Verso com Rapidez e Segurana Uma mensagem de sucesso da instalao ir aparecer, aperte Finish!
3.2. Congurando o Git

Antes de comear a utilizar o Git, alguns ajustes precisam ser feitos. Precisamos denir o nome do nosso usurio e um email, que sero usados para identicar as alteraes que sero realizadas em nosso repositrio. Para que esta congurao seja feita, as variveis globais user.name e user.email do Git precisam ser denidas.
3.2.1. Exerccio
Vamos congurar as variveis globais de usurio e e-mail para utilizar o Git: 1. Abra o terminal em seu Sistema Operacional e digite o comando: ! " git cong --global user.name <NOME DO SEU USURIO> substituindo <NOME DO SEU USURIO> pelo nome de usurio que deseja utilizar.
2. Aps denir o usurio, ainda no terminal, dena o seu e-mail digitando o comando: ! ! git cong --global user.email <SEU ENDEREO DE EMAIL> substituindo <SEU ENDEREO DE EMAIL> pelo seu endereo de e-mail.
3. Verique as conguraes realizadas com o comando: git cong -l
3.3. Criando um repositrio com o Git

Criar um repositrio uma tarefa simples com o Git. Um simples comando git init inicia um repositrio do Git no diretrio atual. Veja o exemplo na Figura 35, onde criamos um repositrio do Git em um diretrio chamado curso-git.
Figura 35. Iniciando um repositrio com o Git.
17
GIT - Controle de Verso com Rapidez e Segurana No exemplo acima criamos um repositrio do Git no diretrio curso-git e logo em seguida listamos seus arquivos. Perceba que um diretrio .git foi criado no diretrio raiz do nosso repositrio. #Fica a dica Quando se cria um repositrio com o Git, apenas um diretrio chamado .git criado na raiz do projeto e este diretrio conter todo o histrico de controle de verso do nosso projeto. Isto uma grande vantagem do Git em comparao a outros SCMs como o CVS, por exemplo, que cria um diretrio .cvs no diretrio raz e em todos os sub-diretrios, poluindo muito o diretrio do nosso projeto. Como apenas um diretrio .git criado, basta delet-lo para deixar de usar o Git como controle de verso do nosso projeto.
3.3.1. Exerccio
Agora que voc aprendeu a criar um repositrio do Git, vamos criar um repositrio chamado curso-git, que ser usado no decorrer do nosso curso. 1. Crie um diretrio chamado curso-git em seu sistema de arquivos local; 2. Abra o terminal do seu Sistema Operacional e entre no diretrio curso-git que foi criado; 3. Execute o comando: git init; 4. Liste os arquivos deste diretrio e perceba o diretrio .git que foi criado.
3.4. Realizando nosso primeiro commit

Agora que ns j temos um repositrio, podemos criar um projeto dentro dele e ter seus arquivos monitorados pelo Git. Para o nosso curso, iremos utilizar um projeto simples: uma pgina html. No diretrio onde o repositrio foi criado, criamos um arquivo pagina.html e denimos apenas um ttulo e um cabealho para esta pgina:
Figura 36. Contedo inicial da nossa pgina
Aps criar o arquivo pagina.html (nosso primeiro arquivo do projeto) e salv-lo, executamos o comando git status e percebemos a seguinte sada:
18
Figura 37. Sada do comando git status
A sada do comando git status nos informou que existe um novo arquivo no repositrio (pagina.html), porm este arquivo ainda no est trackeado pelo Git. Um arquivo no trackeado (untracked) um arquivo que est apenas na rea de trabalho (working directory), onde trabalhamos diretamente com o arquivo. Precisamos ento adicionar este arquivo na rea intermediria (staging area ou Index) antes de fazer um commit. #Fica a dica O comando git status muito til para vericarmos o estado dos nossos arquivos na branch atual. Ele nos informa se h alteraes a serem inseridas na staging area ou se h arquivos na staging area prontos para serem commitados. Para adicionar nosso arquivo pagina.html na rea intermediria, usamos o comando git add:
Figura 38. Adicionando o arquivo pagina.html na staging area
Ao executar o comando git add pagina.html adicionamos o arquivo pagina.html na rea intermediria. Com o comando git status, logo em seguida, podemos vericar que agora nosso arquivo pagina.html est trackeado, ou seja, ele est no Index (staging area) e pronto para ser adicionado denitivamente no repositrio, em nossa branch master. #Fica a dica Uma branch uma ramicao do projeto, um espao contendo uma cpia dos arquivos do repositrio. Ao criar um repositrio com o Git, automaticamente uma branch chamada master criada e esta ser a branch principal do projeto. Com o Git podemos ter quantas branches desejarmos. Aprenderemos mais sobre branch em outro captulo. Agora que nosso arquivo pagina.html est trackeado (adicionado ao Index), podemos realizar o commit, usando o comando git commit.
19
Figura 39. Realizando nosso primeiro commit
Perceba que ao executarmos o comando git commit, o Git emite uma sada nos informando que o arquivo pagina.html foi adicionado ao repositrio, criando uma nova reviso. Aps realizar o commit, o git status informa que nosso working directory est limpo, sem nenhum commit a ser feito. Podemos vericar o Log de commits com o comando git log:
Figura 40. Vericando o Log de commits com o comando git log.
#Fica a dica O comando git log mostra o Log de todos os commits realizados na branch atual. O Log informa o autor do commit, a data e hora em que o commit foi realizado e a mensagem do commit. Perceba no Log que cada commit identicado por uma hash SHA-1 de 40 caracteres hexadecimais. Diferente de SCMs centralizados, onde cada commit recebe um nmero como identicador (sendo que o commit mais recente sempre ter um nmero maior que os anteriores), em SCMs distribudos, como o Git, cada commit identicado por uma hash nica. Sempre que executamos um commit, uma mensagem deve ser informada identicando-o. Veja na Figura 39 onde executamos o comando git commit -m Criando nossa primeira pagina. A ag -m indica que o contedo em seguida a mensagem do commit. Caso a ag -m seja omitida, o prprio Git ir abrir um editor de texto pedindo-o para digitar uma mensagem para o commit a ser realizado. Informar uma mensagem/comentrio em cada commit muito importante para manter um histrico de evoluo do cdigo e facilita a leitura do que foi alterado naquele commit para todos os colaboradores do projeto.
3.4.1. Exerccio
Agora que voc aprendeu a fazer um commit, vamos colocar em prtica. 1. Crie um arquivo chamado pagina.html no diretrio curso-git (onde foi criado o repositrio) com o seguinte contedo:
20
GIT - Controle de Verso com Rapidez e Segurana <html> " <head> " " <title>Curso de Git</title> " </head> " <body> " " <h1>Git - Um SCM rapido e seguro!</h1> " </body> </html> 2. Salve o arquivo e verique o status de alteraes no working directory com o comando git status. 3. Adicione o arquivo criado no staging area com o comando git add pagina.html. 4. Execute novamente o comando git status e perceba as alteraes. 5. Faa o commit com o comando git commit -m Criando nossa primeira pagina. 6. Verique o Log do commit realizado, com o comando git log. 7. Abra o arquivo pagina.html em seu browser e verique seu contedo.
21
4 - Trabalhando em Equipe
Agora que j sabemos criar um repositrio do Git e realizar commit, iremos trabalhar de forma colaborativa. Apesar de ser um SCM distribudo, com o Git podemos facilmente disponibilizar nosso repositrio em um servidor central para que outros desenvolvedores possam colaborar com nosso projeto. Em nosso curso iremos utilizar o GitHub para armazenar nosso repositrio do Git. O GitHub uma ferramenta na Web que nos possibilita compartilhar nosso projeto de forma rpida e possui muitos recursos que facilitam a utilizao do Git. GitHub praticamente uma rede social de desenvolvedores para projetos que usam o Git, permitindo que usurios do mundo inteiro possam ter acesso aos repositrios publicados. O cadastro no GitHub gratuito e voc pode armazenar seus repositrios sem nenhum custo, desde que eles sejam open source. No GitHub possvel ter repositrios privados tambm. Os repositrios privados so pagos, porm seu custo baixo: possvel ter repositrios privados a partir de 7 dlares por ms. Utilizaremos ento um repositrio open source, sem custo mensal.
4.1. Hospedando nosso projeto no GitHub

Agora que j sabemos criar um repositrio local e criar revises com commits, iremos criar um repositrio remoto no GitHub e permitir que outros desenvolvedores possam colaborar com nosso projeto. Para isto, precisamos criar um usurio no GitHub.
4.1.1. Criando uma conta de usurio no GitHub

No site www.github.com basta clicar no link Plans, Pricing and Signup, localizado na pgina inicial. Uma pgina com os planos do GitHub ir se abrir. Basta clicar no link Create a free account para criar uma conta gratuita, sem custos mensais.
Figura 41. Clique no link Create a free account para criar uma conta gratuita no GitHub.
22
GIT - Controle de Verso com Rapidez e Segurana Na tela de cadastro, bastra preencher um nome de usurio, endereo de e-mail e senha da conta, e clicar no link Create an account, conforme a Figura 42.
Figura 42. Formulrio para cadastro de conta no GitHub.com.
Precisamos agora gerar uma chave de segurana e cadastr-la no GitHub para que ele autorize nossa mquina a gerenciar nossos repositrios remotos. Para isto, basta entrar no terminal (para usurios Windows basta abrir o Git Bash) e digitar o seguinte comando: ! ssh-keygen -t rsa -C <SEU ENDEREO DE E-MAIL>
Substitua <SEU ENDEREO DE E-MAIL> pelo seu endereo de e-mail. Aps executar o comando acima, o gerador de chaves ir perguntar em qual arquivo deseja gravar a chave gerada. Basta pressionar <Enter> para que a chave seja gravada no local padro, no arquivo id_rsa dentro do diretrio padro do seu usurio. Uma senha e sua conrmao tambm sero solicitados, bastando pressionar <Enter> nessas duas etapas, pois no iremos travar nossa chave com senha. Veja todo este processo na Figura 43.
Figura 43. Gerando uma chave de segurana RSA para cadastrarmos no GitHub.com.
23
GIT - Controle de Verso com Rapidez e Segurana Com a nossa chave de segurana gerada, precisamos cadastr-la no GitHub. Para isto, com seu usurio logado, v na sesso Account Settings do GitHub e entre no link SSH Keys no menu. Agora basta clicar no link Add SSH Key. Uma pgina de cadastro da chave de segurana ir se abrir. Informe um ttulo para a chave e copie o contedo do arquivo id_rsa.pub do diretrio .ssh (localizado no diretrio home do seu usurio em seu computador) e cole no campo Key do formulrio. Clique em Add key para concluir o cadastro da chave.
Figura 44. Cadastrando uma chave de segurana no GitHub.com
4.1.2. Criando um repositrio no GitHub

Aps criar nossa conta, iremos criar um repositrio remoto no GitHub chamado curso-git. Para isto, basta entrar no GitHub.com com seu usurio e senha cadastrados e clicar no link New repository.
Figura 45. Pgina inicial da conta cadastrada no GitHub.com. Para criar um novo repositrio, basta clicar no link New Repository.
24
GIT - Controle de Verso com Rapidez e Segurana Na pgina de cadastro do novo repositrio, basta preencher um nome e uma descrio para o repositrio, e clicar no link Create repository, conforme Figura 46.
Figura 46. Formulrio de cadastro de novo repositrio no GitHub.com.
Nosso novo repositrio remoto est criado e pronto para ser usado. Agora precisamos congurar nosso repositrio remoto curso-git em nosso repositrio local de mesmo nome para que seja feita a sincronizao entre os dois. Para congurar um repositrio remoto do GitHub em um repositrio local, basta usar o seguinte comando: ! git remote add <NOME DO REPOSITRIO> git@github.com:<USUARIO>/<NOME DO REPOSITRIO>.git
Substituindo <NOME DO REPOSITRIO> por um nome que ser usado para identic-lo (por conveno, o Git recomenda utilizar o nome origin), <USUARIO> pelo nome do usurio cadastrado no GitHub e <NOME DO REPOSITRIO> pelo nome do repositrio cadastrado no GitHub. Em nosso exemplo usaremos o comando: " git remote add origin git@github.com:lucas-hachitecnologia/curso-git.git
Figura 47. Adicionando o repositrio remoto do GitHub em nosso repositrio local.
#Fica a dica O comando git remote add adiciona um repositrio remoto para sincronizarmos com o repositrio local. Aps cadastrar um repositrio remoto podemos enviar todas as nossas alteraes para ele e tambm baixar dele todas as alteraes feitas por outros desenvolvedores. Quando sincronizamos com um repositrio remoto, tanto nosso repositrio local como o remoto conter toda a parte sinttica do projeto (cdigo fonte) bem como todo o histrico de alteraes realizados. Agora que adicionamos um repositrio remoto, podemos enviar a ele todas as nossas alteraes realizadas no repositrio local, para que outros desenvolvedores possam contribuir com o projeto. Para enviar nossas alteraes para o repositrio remoto basta utilizar o comando:
25
GIT - Controle de Verso com Rapidez e Segurana " git push <ALIAS DO REPOSITORIO> <NOME DA BRANCH LOCAL>
Substituindo <ALIAS DO REPOSITORIO> pelo nome que desejamos utilizar para nosso repositrio remoto e <NOME DA BRANCH LOCAL> pelo nome da branch que desejamos sincronizar com o repositrio remoto. No nosso caso, usaremos o seguinte comando: " git push origin master
Veja a Figura 48 mostrando a sincronizao entre os repositrios local e remoto na prtica:
Figura 48. Enviando as revises do repositrio local para o repositrio remoto.
4.1.3. Enviando nossas alteraes ao repositrio do GitHub

A Figura 48 mostra o envio das revises feitas no nosso repositrio local para nosso repositrio remoto, e a sada do Git informa que tudo ocorreu conforme esperado. Agora outros desenvolvedores podero contribuir com nosso projeto fazendo um clone do repositrio remoto e realizando as devidas alteraes. #Fica a dica Quando um desenvolvedor precisa colaborar com um projeto, ele faz um clone do repositrio remoto. Um clone uma cpia el de todo o repositrio, incluindo tanto a parte sinttica do projeto (cdigo fonte) como todo o histrio de revises (alteraes) realizadas no projeto. Desta forma um desenvolvedor tem a liberdade de fazer suas alteraes localmente, gerando suas revises, e somente quando desejar poder sicronizar com o repositrio remoto, enviando todas as suas alteraes feitas.
Ao visualizar nosso repositrio remoto no site GitHub.com podemos ver claramente os arquivos enviados, juntamente com todo o histrico do projeto. Veja:
Figura 49. Visualizando o histrico do nosso projeto no site do GitHub.com.
26
GIT - Controle de Verso com Rapidez e Segurana Perceba na Figura 49 que nosso arquivo pagina.html realmente foi enviado e uma informao mostra claramente o autor do ltimo commit realizado, juntamente com a mensagem de commit.
4.1.4. Exerccio
Agora que voc j sabe como criar um repositrio remoto no GitHub.com e sincronizar com seu repositrio local, vamos colocar em prtica. 1. Crie uma conta no site GitHub.com. 2. Gere uma chave de segurana RSA em seu computador e cadastre-a em sua conta do site GitHub.com. 3. Crie um repositrio remoto chamado curso-git em sua conta no site GitHub.com. 4. Adicione o repositrio remoto curso-git criado no site GitHub.com ao seu repositrio curso-git local. 5. Sincronize seu repositrio local com o repositrio remoto enviando todas suas revises a ele. 6. Abra a pgina do seu repositrio remoto no GitHub.com e perceba as revises enviadas.
4.2. Colaborando com o projeto

Agora que nosso projeto curso-git est hospedado no GitHub, outros desenvolvedores podem colaborar com o projeto enviando suas revises. Por padro, um projeto open source hospedado no GitHub permite que outros usurios faam apenas um clone do repositrio, no permitindo que alteraes sejam enviadas ao repositrio remoto. Para permitirmos que outros desenvolvedores possam contribuir com o projeto, enviando suas alteraes, precisamos autorizar seus usurios.
4.2.1. Adicionando um colaborador ao repositrio do GitHub

No GitHub.com, autorizar um usurio para colaborar com nosso projeto muito simples: basta abrir a rea de administrao do repositrio que criamos, clicando no link Admin na pgina do repositrio, e ir na opo Collaborators do menu. Na rea Collaborators do nosso repositrio curso-git podemos adicionar os usurios que desejamos autorizar como colaboradores do projeto. Veja na Figura 50 o processo de adio de novos colaboradores.
Figura 50. Adicionando um novo colaborador ao nosso repositrio no GitHub.com.
27
GIT - Controle de Verso com Rapidez e Segurana Perceba na Figura 50 que adicionamos o usurio (vigarista-hachitecnologia) pertencente ao Dick Vigarista. Agora Dick Vigarista est autorizado a realizar modicaes em nosso projeto.
4.2.2. Realizando um clone do repositrio remoto

O primeiro passo para Dick Vigarista colaborar com o projeto fazer um clone do repositrio remoto curso-git. O processo de clonar um repositrio remoto no Git muito simples, bastando utilizar o comando do Git: ! git clone git@github.com:<USUARIO>/<NOME DO REPOSITRIO REMOTO>.git
No nosso caso, iremos utilizar o comando abaixo para clonar o repositrio curso-git: " git clone git@github.com:lucas-hachitecnologia/curso-git.git
Veja o processo de clone do repositrio na Figura 51:
Figura 51. Clonando o repositrio remoto curso-git.
Aps fazer o clone, o usurio Dick Vigarista poder trabalhar no projeto fazendo suas alteraes e sincronizando-as com o repositrio remoto. #Fica a dica Quando efetuamos o clone de um repositrio, o Git comprime todos os dados que sero trafegados, usando a biblioteca zlib. Isto otimiza o trfego de dados na rede, e uma vantagem do Git, tornando o processo de sincronizao mais rpido que outros SCMs.
O usurio Dick Vigarista resolve ento alterar o arquivo pagina.html adicionando um novo pargrafo, conforme podemos ver na Figura 52.
Figura 52. O usurio Dick Vigarista adiciona um novo pargrafo no arquivo pagina.html
28
GIT - Controle de Verso com Rapidez e Segurana O git status informa a Dick Vigarista que o arquivo pagina.html foi modicado e est pronto para ser adicionado ao staging area, antes de ser commitado. Quando algum arquivo alterado dizemos que o working directory est sujo, e essas alteraes precisam ser adicionadas ao staging area para serem commitadas.
Figura 53. A sada do comando git status informa que existem novas alteraes a serem publicadas no repositrio.
Para publicar suas alteraes no repositrio local, Dick Vigarista precisa executar a sequncia de comandos: " " git add pagina.html git commit -m <COMENTRIO DO COMMIT>
Figura 54. Dick Vigarista commita suas alteraes no repositrio local e verica o status logo em seguida.
As alteraes foram commitadas no repositrio local de Dick Vigarista. Podemos ver o Log dos commits com o comando git log.
Figura 55. Log de commits mostrando todos os commits existentes no repositrio de Dick Vigarista.
Agora Dick Vigarista possui dois commits em seu repositrio: um commit realizado pelo usurio Lucas Freitas, que criou o arquivo pagina.html, e seu prprio commit.
29
4.2.3. Enviando as alteraes ao repositrio remoto

As alteraes de Dick Vigarista foram commitadas apenas em seu repositrio local. Se vericarmos a pgina do repositrio curso-git no site do GitHub.com percebemos que o repositrio remoto ainda no possui o commit de Dick Vigarista. Para enviar as suas alteraes, Dick Vigarista precisa executar um push ao repositrio remoto, com o seguinte comando: " git push origin master
Figura 56. Enviando as alteraes para o repositrio remoto com git push.
Agora nosso repositrio remoto j possui as alteraes feitas por Dick Vigarista, permitindo que outros desenvolvedores possam baixar essas alteraes. Veja na pgina do repositrio a reviso enviada por Dick Vigarista, na Figura 57.
Figura 57. Log de commits do repositrio remoto, na pgina do GitHub.com.
#Fica a dica Quando efetuamos o clone de um repositrio remoto o Git automaticamente o adiciona em nosso repositrio local, com o alias origin, para realizarmos as sincronizaes posteriores.
4.2.4. Baixando as atualizaes do repositrio remoto

O usurio Dick Vigarista realizou alteraes no projeto e as enviou para o repositrio remoto hospedado no GitHub. Agora outros usurios podero baixar essas atualizaes com um pull, atravs do comando: " git pull origin master 30
Figura 58. Usurio Lucas Freitas baixando as atualizaes do repositrio remoto enviadas por Dick Vigarista.
Veja, na Figura 58, que o usurio Lucas Freitas executou um pull, baixando todas as atualizaes existentes no repositrio remoto. Agora o usurio Lucas Freitas possui as alteraes realizadas pelo usurio Dick Vigarista.
4.2.5. Resoluo manual de conitos

Quando estamos usando um SCM para controle de verso de um projeto, comum dois ou mais desenvolvedores realizarem alteraes no mesmo arquivo. Quando isto ocorre, ao realizar a sincronizao dos repositrios, um merge automtico feito neste arquivo. Mas um problema que pode ocorrer quando dois desenvolvedores resolvem modicar a mesma linha deste mesmo arquivo. Quando isto ocorre, o Git tenta aplicar o merge automtico mas falha, e a nica sada resolver o conito manualmente. Imagine, por exemplo, que o usurio Lucas Freitas decide alterar o ttulo da pgina para: ! ! ! ... ! ...
<title>Curso de Git SCM</title>
Aps realizar a alterao, Lucas Freitas faz o commit e a envia para o repositrio remoto. Enquanto isso, o usurio Dick Vigarista decide tambm alterar o ttulo da pgina em seu repositrio local, deixando-o com o seguinte contedo: ! ! ! ... ! ...
<title>Curso sobre o SCM Git</title>
Dick Vigarista realiza o commit em seu repositrio local mas, quando tenta enviar suas alteraes para o repositrio remoto, o push rejeitado e o Git emite um erro informando que sua base de commits est desatualizada, sendo necessrio baixar do repositrio remoto todos os commits que seu repositrio local ainda no possui
31
Figura 59. Dick Vigarista tenta enviar suas alteraes mas o repositrio remoto as rejeita, devido sua base de commits estar desatualizada.
Para resolver este problema, Dick Vigarista dever realizar um pull para baixar as novas alteraes do repositrio remoto. Ao realizar o pull, o Git ir informar que um problema ocorreu ao fazer o merge automtico devido ao usurio Lucas Freitas tambm ter alterado a mesma linha do arquivo pagina.html.
Figura 60. Dick Vigarista executa o pull para baixar as novas alteraes do repositrio remoto, mas o merge automtico falha.
Quando o merge automtico falha, o Git cria uma branch temporria para que o conito seja resolvido. Veja como cou o arquivo aps o conito:
Figura 61. Contedo do arquivo pagina.html aps o conito ocorrido ao executar o merge automtico.
Agora Dick Vigarista precisa resolver o conito manualmente, decidindo qual contedo ir permanecer no ttulo da pgina. Dick Vigarista resolve o conito, deixando o ttulo com o seguinte contedo: ! ! ! ... ! ...
<title>Curso sobre o SCM Git</title>
Agora que Dick Vigarista editou o arquivo para resolver o conito manualmente, basta adicionar o arquivo no Index (staging area) e realizar o commit com a nova alterao.
32
4.2.6. Git blame, o famoso dedo-duro

O Git possui um recurso muito til que nos mostra o autor de cada linha de um arquivo em nosso repositrio, bem como a data em que a linha foi alterada/adicionada, a hora e a hash do commit. Isto muito til para sabermos quem fez determinada modicao ou quem causou um determinado bug em um arquivo do cdigo fonte, ou seja, um grande dedoduro. O git blame possui a seguinte sintaxe: " git blame <ARQUIVO>
Veja, na Figura 62, a sada do git blame no arquivo pagina.html:
Figura 62. Sada do git blame no arquivo pagina.html.
4.2.7. Exerccio
Agora que voc j sabe contribuir com um repositrio remoto, vamos colocar em prtica: 1. Crie outro usurio no GitHub.com (no esquea de cadastrar sua chave de segurana). 2. Adicione o novo usurio como colaborador do repositrio curso-git. 3. Faa um clone do repositrio a partir do novo usurio. 4. Modique o arquivo pagina.html adicionando um novo pargrafo, deixando-o com o seguinte contedo: <html> ! <head> ! ! <title>Curso de Git</title> ! </head> ! <body> ! ! <h1>Git - Um SCM rapido e seguro!</h1> ! ! <p>O Git foi criado por Linus Torvalds</p> ! </body> </html> 5. Salve o arquivo e faa o commit no repositrio local. 6. Envie as alteraes para o repositrio remoto do GitHub.com. 7. Baixe as alteraes do repositrio remoto com o primeiro usurio que voc cadastrou no GitHub.com.
33
5 - Recursos avanados do Git
5.1. Trabalhando com branches

Uma branch uma ramicao do projeto, uma cpia paralela do projeto que nos permite realizar modicaes sem alterar o projeto original. Trabalhar com branches (ramicaes) no Git uma tarefa fcil. A vantagem em se utilizar uma branch simples: imagine que voc est trabalhando em seu projeto e seu chefe solicita uma correo imediata de um bug ou uma rpida alterao no cdigo, como mudar uma label ou trocar a cor de um boto. Quem trabalha com desenvolvimento de software vivencia diariamente essas mudanas de prioridade. Usando branches, no Git, voc pode trabalhar no novo requisito sem ter que perder todas as alteraes que havia feito antes da nova solicitao. Isto muito til, j que no queremos commitar nossas alteraes pela metade ou ter que descartar todas elas para atender nova solicitao e refaz-las em outro momento. Uma boa prtica trabalhar sempre com uma branch local que no seja a master (branch padro). Desta forma polumos menos nosso projeto com commits indesejados e organizamos melhor as nossas revises na branch master.
5.1.1. Criando uma branch

Para criar uma branch, basta executar o comando: " git branch <NOME DA BRANCH>
substituindo <NOME DA BRANCH> pelo nome desejado. Vamos criar uma branch chamada desenvolvimento em nosso repositrio local, usando o comando: " git branch desenvolvimento
Figura 63. Criando uma branch desenvolvimento.
#Fica a dica Podemos visualizar as branches do nosso repositrio local apenas digitando o comando: git branch.
5.1.2. Alternando entre branches

Nossa branch desenvolvimento est criada, porm ainda estamos na branch master e precisamos alternar para a nova branch com o comando: " git checkout desenvolvimento
#Fica a dica Podemos criar uma branch e alternar para ela utilizando um nico comando: git checkout -b desenvolvimento.
34
5.1.3. Trabalhando com a nova branch

Imagine que queremos fazer algumas alteraes em nosso projeto e envi-las ao repositrio apenas quando estiverem maduras e homologadas. Podemos usar nossa branch desenvolvimento para isto. Para exemplicar, vamos alterar nosso projeto adicionando uma folha de estilo em nossa pgina, mas iremos fazer isso na branch desenvolvimento. Criamos o arquivo estilo.css na branch desenvolvimento com o seguinte contedo:
Figura 64. Criando uma folha de estilo para nossa pgina.
Denimos a cor vermelha para o cabealho e a cor azul para os pargrafos. Precisamos agora aplicar a folha de estilo em nossa pgina, no arquivo pagina.html, conforme Figura 65.
Figura 65. Aplicando o estilo em nossa pgina.
Aps criar a folha de estilo e aplic-la em nossa pgina, vamos realizar um commit das alteraes feitas na branch desenvolvimento.
35
Figura 66. Realizando o commit das alteraes realizadas na branch desenvolvimento.
Realizamos as alteraes na branch desenvolvimento e zemos o commit destas alteraes. Perceba que as alteraes foram commitadas apenas na branch desenvolvimento. Podemos vericar isso claramente quando comparamos o Log de commits da branch desenvolvimento com os da branch master.
Figura 67. Log da branch desenvolvimento.
Figura 68. Log da branch master. Perceba que as alteraes realizadas na branch desenvolvimento no reetiram na branch master.
Se uma nova prioridade no projeto for solicitada, como a correo de um bug por exemplo, e nossas alteraes no estiverem maduras o suciente para irem para a produo, podemos voltar para a branch master e realizar as novas solicitaes, sem perdermos o nosso trabalho. Imagine que seu chefe tenha pedido para adicionar um novo pargrafo pgina, mas ele no quer que a folha de estilo que aplicamos entre em produo, pois ela ainda no est completa. Como as modicaes que zemos no foram feitas na branch master, car fcil atender a essa nova solicitao. Voltaremos para a branch master com o comando: " git checkout master 36
GIT - Controle de Verso com Rapidez e Segurana e adicionamos o novo pargrafo ! <p>O Git e um SCM distribuido.<\p>
Aps a alterao, realizamos um commit na branch master e a verso est pronta para ser usada em produo.
Figura 69. Realizando o commit das novas alteraes solicitadas.
Porm, ao abrir a pgina, seu chefe percebe que existe um bug causado pelo mal fechamento da tag de pargrafo, onde adicionamos <\p> ao invs de </p>, acarretando no mal funcionamento do site. Devemos ento corrigir o bug causado, trocando o pargrafo bugado de " para ! <p>O Git e um SCM distribuido.</p> <p>O Git e um SCM distribuido.<\p>
Realizamos ento um commit com a correo do bug, gerando uma nova reviso.
Figura 70. Realizando um commit com a correo do bug.
37
GIT - Controle de Verso com Rapidez e Segurana #Fica a dica Para adicionar as alteraes realizadas na staging area e commit-las ao mesmo tempo, podemos usar a ag -a no commit: ! git commit -am <MENSAGEM DO COMMIT>
Agora iremos dar continuidade ao nosso trabalho na branch desenvolvimento. Para isto, executamos novamente o comando: " git checkout desenvolvimento
para voltar para a branch desenvolvimento. Podemos agora realizar as alteraes que faltam em nossa folha de estilo. Seu chefe pediu que fosse adicionado um recurso para centralizar os cabealhos da pgina, e faremos isto na folha de estilo, deixando-a com o seguinte contedo:
Figura 71. Adicionando um recurso para centralizar os cabealhos em nossa pgina.
Realizada a alterao, executamos o commit:
Figura 72. Commitando as alteraes realizadas na branch desenvolvimento.
38
5.1.4. Enviando as alteraes para a branch master

Agora que nossas alteraes na branch desenvolvimento esto prontas, hora de envi-las para a branch master. Mas para isso, precisamos estar atualizados em relao aos commits da branch master que ainda no possumos na branch desenvolvimento. Existem dois commits na branch master que a branch desenvolvimento ainda no possui. Se simplesmente jogssemos os commits da branch desenvolvimento na branch master, sem que ela esteja com a base de commits atualizada em relao branch master, correramos o risco de vrios conitos ocorrerem, sujando o log de commits do nosso projeto. Para atualizar a nossa base de commits da branch desenvolvimento, precisamos puxar os commits da branch master que ainda no possumos. Para isto, basta utilizar o comando: " git rebase master
Figura 73. Commitando as alteraes realizadas na branch desenvolvimento.
Agora que temos todos os commits da branch master podemos enviar as alteraes feitas na branch desenvolvimento para ela. Para isto, precisamos alternar para a branch master, com o comando: " git checkout master
Estando na branch master, podemos puxar as alteraes da branch desenvolvimento com o comando: " git merge desenvolvimento
Figura 74. Puxando os commits da branch desenvolvimento para a branch master.
39
GIT - Controle de Verso com Rapidez e Segurana Pronto! Nossa branch master agora possui todos os commits realizados na branch desenvolvimento. Podemos agora enviar nossos commits para o repositrio remoto, com o comando: " git push origin master
5.1.5. Resolvendo conitos no rebase

No exemplo anterior, o rebase realizado para atualizar a base de commits da branch desenvolvimento ocorreu com sucesso. Mas e se outro desenvolvedor tivesse editado na branch master o mesmo arquivo que editamos na branch desenvolvimento alterando as mesmas linhas? Isto com certeza iria gerar um conito na hora do rebase. Imagine que o usurio Dick Viragista decide alterar o pargrafo: ! <p>O Git foi criado por Linus Torvalds</p>
mudando-o para o seguinte contedo: " <p>O Git foi criado por Linus Torvalds para desenvolver o Kernel do Linux.</p>
Aps realizar suas alteraes, Dick Vigarista realiza um commit na branch master e envia sua reviso para o repositrio remoto.
Figura 75. Dick Vigarista commita suas alteraes e as envia para o repositrio remoto.
Mas o usurio Lucas Freitas tambm decide alterar o mesmo pargrafo, deixando-o com o seguinte contedo: ! <p>O Git foi criado por Linus Torvalds, o pai do Linux.</p>
O usurio Lucas Freitas commita sua alterao na branch desenvolvimento
Figura 76. Lucas Freitas faz suas alteraes e as commita na branch desenvolvimento.
40
GIT - Controle de Verso com Rapidez e Segurana Agora Lucas Freitas precisa enviar sua alterao da branch desenvolvimento para a branch master. Mas para isso, Lucas Freitas precisa atualizar sua base de commits puxando as novas alteraes da branch master. Lucas Freitas faz um pull em sua branch master para puxar as alteraes feitas por outros usurios, no caso a alterao feita por Dick Vigarista.
Figura 77. Lucas Freitas baixa as alteraes do repositrio remoto para a branch master local.
Agora Lucas Freitas possui em sua branch master local todas as alteraes existentes no repositrio remoto, enviada por outros usurios. Porm, sua branch local desenvolvimento ainda no possui essas alteraes. O usurio Lucas Freitas dever agora fazer o rebase na branch desenvolvimento para atualizar a base de commits de acordo com a branch master. Ao realizar o rebase, um conito ocorre, gerando a seguinte sada:
Figura 78. Lucas Freitas realiza o rebase na branch master e percebe que ocorreram conitos.
O Git informou que foi encontrado um conito no arquivo pagina.html, ocorrido durante o merge automtico no arquivo, devido s alteraes realizadas pelos dois usurios na mesma linha do cdigo. Quando um conito ocorre durante o rebase, o Git cria uma branch temporria para que o conito seja resolvido. Isto ocorrer em todos os commits que gerarem
41
GIT - Controle de Verso com Rapidez e Segurana conito na hora do rebase, e deveremos resolver um a um. Perceba na Figura 79 que ao executar o comando git branch, o Git nos informa que estamos em uma branch chamada de (no branch), que uma branch temporria.
Figura 79. O Git informa que estamos em uma branch temporria, chamada de (no branch), para resolver os conitos do rebase.
No aviso do conito, na Figura 78, o prprio Git nos informa trs possveis solues para resolv-lo: 1. Usar o comando git rebase --skip para descartar o nosso commit, substituindo-o pelo commit feito por Dick Vigarista; 2. Usar o comando git rebase --abort para cancelar o rebase e descartar as atualizaes vindas do branch master; 3. Ou resolver os conitos manualmente, decidindo qual o contedo que dever car no arquivo pagina.html, e usar o comando git rebase --continue aps resolver estes conitos para dar continuidade ao rebase.
Veja o contedo do arquivo pagina.html aps o conito:
Figura 80. Contedo do arquivo pagina.html com o conito, aps o rebase.
O comando git status nos informa a mensagem both modied: pagina.html indicando que ambos os desenvolvedores alteraram o mesmo arquivo, gerando um conito. Devemos resolver o conito para que esta mensagem desaparea.
Figura 81. Sada do comando git status informando que existe um conito no arquivo pagina.html.
42
GIT - Controle de Verso com Rapidez e Segurana Optaremos por resolver o conito manualmente, conforme aprendemos anteriormente no curso, decidindo car com o contedo de Lucas Freitas para o pargrafo 1 da pgina. Alteramos ento o arquivo, para que ele que com o seguinte contedo:
Figura 82. Contedo do arquivo pagina.html aps resoluo do conito gerado pelo rebase.
Aps resolver os conitos manualmente, adicionamos o arquivo pagina.html ao Index, com o comando: " git add pagina.html
Vericando o status, percebemos que agora a mensagem both modied desapareceu, conforme Figura 83.
Figura 83. O status mostra que o conito foi resolvido.
Aps ter resolvido todos os conitos, podemos dar continuidade ao rebase com o comando: " git rebase --continue
Figura 84. Dando continuidade ao rebase, aps resolvidos os conitos.
43
GIT - Controle de Verso com Rapidez e Segurana Agora que resolvemos os conitos gerados pelo rebase, podemos enviar nossas alteraes para a branch master, executando os comandos: " ! git checkout master git merge desenvolvimento
Figura 85. Puxando os commits da branch desenvolvimento para a branch master.
Pronto! Nossas alteraes esto na branch master e prontas para serem enviadas para o repositrio remoto, usando o comando: " git push origin master
Figura 86. Enviando as alteraes da branch master local para o repositrio remoto.
5.1.6. Enviando uma branch local para o repositrio remoto

A branch desenvolvimento existe apenas em nosso repositrio local e, mesmo realizando um push da branch master para o repositrio remoto, a branch desenvolvimento no ser enviada. Para enviar nossa branch desenvolvimento para o repositrio remoto, para que outros desenvolvedores possam trabalhar nesta branch e contribuir com alteraes, devemos alternar para esta branch (com o comando git checkout desenvolvimento) e executar o seguinte comando: " git push -u origin desenvolvimento
#Fica a dica Para listarmos as branches existentes no repositrio remoto, usamos o comando " git branch -r
44
Figura 87. Enviando a branch desenvolvimento para o repositrio remoto.
Pronto! Nossa branch desenvolvimento foi enviada para o repositrio remoto. Agora outros desenvolvedores podem contribuir com alteraes nesta branch. Perceba na Figura 87 a sada do comando git branch -r, listando as branches remotas, mostrando que a branch desenvolvimento agora existe no repositrio remoto.
5.1.7. Baixando uma branch do repositrio remoto para o repositrio local

Caso um usurio queira baixar a branch desenvolvimento do repositrio remoto para contribuir com ela, basta atualizar seu repositrio local (com o comando git pull) e executar o comando: " git branch -t desenvolvimento origin/desenvolvimento
Figura 88. Usurio Dick Vigarista baixando a branch desenvolvimento do repositrio remoto para o repositrio local.
5.1.8. Exerccio
Agora que voc aprendeu a trabalhar com branch, vamos colocar em prtica: 1. Crie uma branch chamada desenvolvimento. 2. Adicione um arquivo chamado estilo.css na nova branch com o seguinte contedo: h1 { color: red; } p{ color: blue; }
45
GIT - Controle de Verso com Rapidez e Segurana 3. Aplique a folha de estilo (estilo.css) que criamos ao arquivo pagina.html, conforme cdigo abaixo: ... <head> ! <title>Curso de Git</title> ! <link rel="stylesheet" type="text/css" href="estilo.css" > </head> ... 4. Faa o commit das alteraes feitas na branch desenvolvimento. 5. Volte para a branch master e adicione um novo pargrafo no arquivo pagina.html com o seguinte contedo: ... ! ...
<p>O Git e um SCM distribuido.<\p>
6. Execute o commit na branch master com as alteraes realizadas. 7. Agora altere novamente o arquivo pagina.html, corrigindo o bug na tag de pargrafo, modicando seu contedo de: ... ! ... para ... ! ...
<p>O Git e um SCM distribuido.<\p>
<p>O Git e um SCM distribuido.</p>
8. Realize o commit na branch master com a correo do bug. 9. Volte para a branch desenvolvimento e altere o arquivo estilo.css, adicionando o recurso de centralizar os cabealhos, deixando-o com o seguinte contedo: h1 { color: red; text-align: center; } p{ color: blue; } 10. Realize o commit das alteraes na branch desenvolvimento. 11. Realize o rebase na branch desenvolvimento para puxar a base de commits atualizada da branch master. 12. Envie os commits da branch desenvolvimento para a branch master local. 13. Envie todas as atualizaes da branch master para o repositrio remoto.
46
5.2. Etiquetando nosso cdigo com tags

Quando estamos trabalhando em um projeto de software, um processo comum a gerao de uma nova release, onde o cdigo estvel e homologado do projeto compilado e publicado em produo. Muitas vezes preciso ter guardado o cdigo fonte desta verso, caso em um determinado momento futuro decidimos compilar a aplicao exatamente como ela estava nessa verso especca, ou ento para vericarmos uma particularidade no cdigo desta verso. No Git isto possvel atravs das tags, que nos possibilita denir uma etiqueta (como verso v1.0, por exemplo) a um determinado ponto em nosso projeto. Outra grande vantagem no uso de tags que podemos comparar a diferena entre uma tag e outra, vericando, por exemplo, o que mudou no sistema da verso v1.0 pra verso v2.0.
5.2.1. Criando uma tag

Criar uma tag no Git simples, e podemos fazer isto com um simples comando: ! git tag -am <MENSAGEM> <NOME DA TAG>
substituindo <MENSAGEM> por uma mensagem sobre a verso que est sendo etiquetada, e <NOME DA TAG> pelo nome que deseja atribuir tag. #Fica a dica Para listar as tags do nosso repositrio, usamos o comando: " git tag
Vamos criar uma tag para etiquetar a verso 1.0 do nosso projeto, usando o comando: ! git tag -am Verso 1.0 do Sistema v1.0
Figura 89. Criando uma tag para identicar a Verso 1.0 do nosso projeto.
Para mostrar melhor o uso de uma tag, vamos realizar uma alterao na branch master e chamar o novo estado do projeto de Verso 2.0. Para isto, iremos adicionar mais um pargrafo em nosso arquivo pagina.html, com o seguinte contedo: ... ! ...
<p>O Git foi escrito em linguagem C.</p>
Realizamos o commit com a nova alterao e criamos uma tag com a etiqueta v2.0.
47
Figura 90. Criando uma tag para identicar a Verso 2.0 do nosso projeto.
Agora temos duas tags em nosso repositrio. Uma identicando a Verso 1.0 e outra identicando a Verso 2.0 do nosso projeto. Caso seja necessrio voltar Verso 1.0, para vericar como estava o cdigo nessa verso ou mesmo para gerar novamente uma release com essa verso, basta realizar um checkout para a tag v1.0, usando o comando: ! git checkout v1.0
Podemos tambm vericar a diferena entre uma tag e outra, usando o comando: " git di# <TAG 1> <TAG 2>
Veja a sada do di# mostrando a diferena entre as Verses 1.0 e 2.0 do nosso sistema:
Figura 91. Vericando a diferena entre as Verses 1.0 e 2.0 do nosso projeto, com o comando git diff.
Verique a sada do di# mostrando que a diferena entre as duas verses exatamente a linha: ! + <p>O Git foi escrito em linguagem C.</p>
que adicionamos na Verso 2.0 da nossa pgina. O + signica que a linha foi adicionada. Caso a linha tivesse sido removida da Verso 1.0 pra 2.0 o smbolo seria -.
5.2.2. Exerccio
Agora que aprendemos a trabalhar com tags, vamos colocar em prtica: 1. Crie uma tag na branch master com a etiqueta v1.0. 2. Faa uma alterao no arquivo pagina.html, adicionando um novo pargrafo com o contedo: ... ! ...
<p>O Git foi escrito em linguagem C.</p>
48
GIT - Controle de Verso com Rapidez e Segurana ! e realize o commit desta alterao.
3. Crie uma nova tag com a etiqueta v2.0. 4. Verique a diferena entre as duas tags que voc criou, usando o di#.
5.3. Usar o di# faz toda a diferena

Como vimos anteriormente, o di# pode ser usado para vericar a diferena de contedo entre tags, mostrando o resultado no formato de um patch. Mas o di# vai muito alm.
5.3.1. Mostrando as alteraes realizadas no working directory

Podemos usar o di# tambm para vericar as alteraes realizadas em nosso working directory que ainda no foram commitadas, apenas digitando o comando: " git di#
Veja a sada do comando git di# aps inserirmos um novo pargrafo em nosso arquivo pagina.html:
Figura 92. Comando git diff mostrando as alteraes realizadas em nosso working directory que ainda no foram commitadas.
5.3.2. Mostrando a diferena entre dois commits

Tambm podemos utilizar o di# para vericar a diferena entre um commit e outro, atravs da hash identicadora do commit, usando a sintaxe: " git di# <HASH 1> <HASH 2>
Veja a sada do comando di# mostrando a diferena entre dois commits realizados:
Figura 93. Comando git diff mostrando diferena entre dois commits realizados em nosso repositrio.
49
5.3.3. Mostrando a diferena entre o commit atual e commits anteriores

O Git tambm disponibiliza uma maneira fcil para vericar a diferena entre um commit anterior especco em relao ao commit atual. Vamos vericar por exemplo a diferena entre o commit atual e trs commits atrs, usando o comando: " git di# HEAD~3
Figura 94. Comando git diff mostrando diferena entre dois commits realizados em nosso repositrio.
#Fica a dica A palavra HEAD utilizada no Git como um ponteiro para a branch atual. Portanto lembre-se: HEAD no uma branch, mas apenas um ponteiro para a branch atual.
5.3.4. Exerccio
Agora que voc aprendeu a trabalhar com o diff, vamos colocar em prtica. 1. Realize uma alterao no arquivo pagina.html, na branch master, adicionando um pargrafo com o seguinte contedo: ... " ... !
<p>O Git no depende de um repositrio central.</p>
mas NO faa o commit desta alterao.
2. Verique as diferenas realizadas no working directory e que ainda no foram commitadas. 3. Verique a diferena entre dois commits quaisquer, realizados em sua branch master. 4. Verique a diferena entre o commit atual e trs commits atrs.
5.4. Desfazendo alteraes

Quando estamos trabalhando com controle de verso em um projeto de software comum s vezes realizarmos commits por acidente, ou incompletos, e querermos desfaz-los, ou mesmo voltar a um estado anterior do nosso cdigo fonte. Para resolver este problema o Git possui recursos que nos permite desfazer alteraes no working directory, no Index ou no HEAD. Outro recurso interessante a possibilidade de podermos procurar por um bug commitado no repositrio e corriglo.
50
5.4.1. Descartando alteraes no working directory

Se alguma alterao foi realizada em um arquivo no working directory, mas por algum motivo voc decide desfazer estas alteraes e voltar ao estado em que este arquivo estava no ltimo commit, possvel faz-lo usando o comando: " ! git checkout <ARQUIVO> Substituindo <ARQUIVO> pelo nome do arquivo que deseja desfazer as alteraes.
Para ver seu funcionamento, vamos alterar o arquivo pagina.html adicionando o seguinte pargrafo: ... ! ...
<p>O Git nao depende de um repositorio central.</p>
Aps ter alterado o arquivo pagina.html podemos desfazer suas alteraes e voltar ao estado do ltimo commit, usando o comando: " git checkout pagina.html
Figura 95. Desfazendo as alteraes realizadas no arquivo pagina.html em nosso working directory.
Perceba, no exemplo, que usamos o di# para vericar as alteraes realizadas no arquivo pagina.html, no working directory, antes de descartar as alteraes. Logo em seguida, aps o descarte, usamos o di# novamente e vericamos que realmente as alteraes do arquivo pagina.html foram descartadas. #Fica a dica Lembre-se que j usamos o comando git checkout anteriormente, mas para alternar entre branches e entre tags. O git checkout tem vrias utilidades, e pode ser usado para: Alternar entre branches, usando a sintaxe: " git checkout <NOME DA BRANCH>
Alternar entre tags, usando a sintaxe: " git checkout <NOME DA TAG>
Desfazer alteraes em um arquivo no working directory, usando a sintaxe: " " git checkout <ARQUIVO>
Navegar para um commit especco, usando a sintaxe: " git checkout <HASH DO COMMIT>
51
GIT - Controle de Verso com Rapidez e Segurana 5.4.1.1. Exerccio Agora que aprendemos a descartar alteraes no working directory, vamos colocar em prtica. 1. Altere o arquivo pagina.html adicionando o seguinte pargrafo: ... ! ... !
mas NO adicione esta alterao ao Index, e nem faa o commit.
2. Descarte a alterao que voc realizou no working directory.
5.4.2. Descartando alteraes no Index

Assim como no working directory, possvel tambm descartar alteraes enviadas staging area (Index), mas o processo um pouco diferente. Para descartar alteraes no Index, usamos a seguinte sintaxe: " git reset HEAD <ARQUIVO>
Para exemplicar, vamos alterar o arquivo pagina.html, adicionando novamente o pargrafo: ... ! ...
Aps salvar o arquivo com a alterao e adicion-lo ao Index (usando o comando git add pagina.html), ele est pronto para ser commitado. Porm, em alguns casos, podemos mudar de idia e desfazer a alterao, caso nececessrio. Mesmo tendo adicionado nossas alteraes ao Index, decidimos ento desfaz-la, usando o comando: " git reset HEAD pagina.html
Figura 96. Desfazendo alteraes no arquivo pagina.html adicionadas ao Index.
Perceba, no exemplo da Figura 96, que adicionamos nossa alterao feita no arquivo pagina.html e a adicionamos ao Index. Logo em seguida, a sada do comando git status nos informa que o arquivo foi modicado e j est no Index, pronto para ser commitado. Porm mudamos de idia e desfazemos a alterao com o comando git reset HEAD pagina.html. Logo em seguida a sada do git status nos mostra que as alteraes j NO esto mais no Index, e sim no working directory.
52
GIT - Controle de Verso com Rapidez e Segurana Como voc pde perceber, quando desfazemos uma alterao no Index, esta volta para o working directory. Se desejar desfazer esta alterao tambm no working directory, basta realizar o procedimento para descartar as alteraes no working directory, conforme aprendemos anteriormente neste curso. 5.4.2.1. Exerccio Agora que voc aprendeu a descartar alteraes no Index, vamos colocar em prtica. 1. Altere o arquivo pagina.html, adicionando o seguinte pargrafo: ... ! ... !
e adicione a alterao ao Index, SEM fazer o commit.
2. Descarte a alterao que voc realizou no Index. 3. Descarte a alterao tambm no working directory.
5.4.3. Descartando alteraes do ltimo commit

Vimos anteriormente como descartar alteraes no working directory e no Index, porm muitas vezes acabamos por commitar alteraes indevidas, ou mudamos de idia e decidimos desfazer alteraes aps o commit. O Git nos permite desfazer o ltimo commit, ou seja, deixar tudo como estava de acordo com o penltimo commit realizado. Para que isto seja feito, basta usar a sintaxe: ! git reset <HASH DO PENLTIMO COMMIT>
Seguindo nosso projeto, vamos novamente adicionar em nosso arquivo pagina.html o pargrafo: ... ! ...
Mas desta vez adicionamos as alteraes no working directory e a commitamos. Logo em seguida, por algum motivo, mudamos de idia e queremos desfazer o commit realizado. Veja o processo sendo realizado na Figura 97.
Figura 97. Desfazendo alteraes do ltimo commit.
53
GIT - Controle de Verso com Rapidez e Segurana No exemplo da Figura 97 executamos um git reset passando como parmetro a hash do penltimo commit, pois queremos voltar ao estado em que o repositrio se encontrava no penltimo commit, descartando o ltimo commit. Se executarmos o git log, percebemos que o ltimo commit realmente foi descartado. Mas quando executamos um git status percebemos que as alteraes do ltimo commit, que descartamos, foram revertidas para o working directory. Portanto, se desejar descartar essas alteraes tambm no working directory, basta realizar o procedimento para descartar as alteraes no working directory, conforme aprendemos anteriormente neste curso.
5.4.3.1. Exerccio Agora que voc aprendeu a descartar alteraes do ltimo commit, vamos colocar em prtica. 1. Altere o arquivo pagina.html, adicionando o seguinte pargrafo: ... ! ... !
e faa o commit.
2. Descarte a alterao que voc realizou neste ltimo commit. 3. Descarte a alterao tambm no working directory.
5.4.4. Descartando alteraes de um commit antigo

A opo de descartar commits, usando o git reset, funciona perfeitamente para o ltimo commit, mas no bom us-la em commits mais antigos. Descartar commits mais antigos uma tarefa um pouco delicada, ainda mais se esses commits j foram enviados para um repositrio remoto correndo o risco de outros desenvolvedores j os terem baixado. Ainda assim o GIT dispe de um recurso capaz de reverter um commit mais antigo. Trata-se do comando git revert. O comando git revert ir reverter as alteraes do commit desejado e fazer um commit novo, descartando estas alteraes. Para isto nosso working directory deve estar limpo, ou corremos o risco de perder as alteraes realizadas nele. Uma boa alternativa usar a opo "-n" para que as alteraes sejam revertidas a adicionadas no working directory. Para exemplicar, vamos realizar uma alterao no cabealho do nosso arquivo pagina.html para o seguinte contedo: ... ! ... "
<h1>Git - O SCM feito da maneira correta!</h1>
e logo em seguida fazemos o commit.
Aps alterar o cabealho e fazer o commit, vamos adicionar os seguintes pargrafos no arquivo pagina.html: ...
!
! ... "
<p>O Git nao depende de um repositorio central.</p> <p>O Git foi criado inicialmente para desenvolver o Kernel do Linux.</p>
Agora iremos adicionar mais um paragrafo no arquivo pagina.html com um link para a pgina ocial do Git, com o seguinte contedo:
54
GIT - Controle de Verso com Rapidez e Segurana ... ! ... "
<p><a href="http://www.git-scm.com">Link para o site oficial do Git</a></p>
Depois de realizar estes trs commits, mudamos de idia e percebemos que no queriamos alterar o cabealho, como zemos h trs commits atrs. Se utilizarmos o git reset nesta situao, perderamos todos os commits realizados aps a alterao do cabealho, pois o git reset usado para descartar apenas o ltimo commit, como vimos anteriormente. Para solucionar nosso caso, de desfazer a alterao do cabealho que zemos h trs commits atrs, usaremos o comando git revert, com a seguinte sintaxe: " git revert <HASH DO COMMIT A SER DESFEITO>
Quando usamos o git revert, o Git abre um editor de texto para informarmos a mensagem que ser usada para o commit automtico que ser feito desfazendo as alteraes. Veja o processo de revert na Figura 98.
Figura 98. Desfazendo alteraes de um commit antigo usando o git revert.
Perceba, na Figura 98, que revertemos o commit com a alterao do cabealho sem afetarmos os commits posteriores. No log podemos ver a mensagem que foi inserida no commit do revert: Revertendo a alterao de cabealho. Essa mensagem foi inserida manualmente no editor de texto aberto pelo Git (apenas no mostramos esse passo). Agora nosso cabealho cou exatamente como estava no incio do projeto, com o seguinte contedo: ... ! ...
<h1>Git - Um SCM rapido e seguro!</h1>
5.4.4.1. Exerccio Agora que voc aprendeu a descartar alteraes em um commit antigo, vamos colocar em prtica: 1. Altere cabealho do arquivo pagina.html, deixando-o com o seguinte contedo: ... ! ... !
<h1>Git - O SCM feito da maneira correta!</h1>
e faa o commit.
2. Altere novamente o arquivo pagina.html, adicionando os seguintes pargrafos:
55
GIT - Controle de Verso com Rapidez e Segurana ...
!
! ... !
<p>O Git nao depende de um repositorio central.</p> <p>O Git foi criado inicialmente para desenvolver o Kernel do Linux.</p>
e faa o commit.
3. Faa mais uma alterao no arquivo pagina.html, adicionando mais o seguinte pargrafo: ... ! ... !
<p><a href="http://www.git-scm.com">Link para o site oficial do Git</a></p>
e faa o commit.
4. Agora reverta (desfaa) a alterao de cabealho realizada no tem de nmero 1 deste exerccio.
5.5. Procurando bugs em commits antigos

Vimos que o GIT tem recursos avanados para descartar commits antigos em nosso projeto. Mas imagine a situao onde um bug foi commitado no projeto mas no sabemos em qual commit ele foi inserido. Sabendo a data aproximada de quando o bug foi commitado podemos ca-lo atravs de um recurso avanado do GIT, chamado git bisect. O git bisect nos exime de ter que dar o checkout commit por commit at achar o bug que procuramos. Imagine, por exemplo, que um usurio telefone informando que h um bug no sistema, mas que h 4 dias atrs no existia esse bug. Com o git bisect podemos procurar esse bug pela data aproximada. Para exemplicar, vamos fazer uma alterao no cabealho da nossa pgina, deixando-o com o seguinte contedo: ... ! ...
<h1>Git - O SCM feito da maneira correta!<\h1>
Realizamos o commit e logo em seguida adicionamos outro pargrafo em nossa pgina, com o seguinte contedo: ... ! ...
<p><a href="http://www.git-scm.com/download">Link para download do Git</a></p>
Realizamos novamente o commit e decidimos adicionar mais um pargrafo, com o seguinte contedo: ... ! ...
<p><a href="http://www.git-scm.com/documentation">Link para documentacao do Git</a></p>
Finalmente, realizamos mais uma alterao na pgina, adicionando o pargrafo abaixo e realizando o commit: ... ! ...
<p><a href="http://www.git-scm.com/about">Link para informacoes sobre o Git</a></p>
Aps realizar essas alteraes, um usurio telefonou para o suporte e informou que a pgina est com um bug, mas que esse bug no existia h 4 dias atrs. Trata-se de um bug inserido na tag do cabealho, quando o alteramos, fechando a tag incorretamente com a barra invertida, cando: <\h1>.
56
GIT - Controle de Verso com Rapidez e Segurana Em nosso exemplo, realizamos apenas 3 commits aps a alterao que foi commitada com bug. Mas imagine um cenrio onde dezenas de commits tenham sido realizados aps a insero de um bug no sistema. Ficaria bem mais difcil encontrlo, se no fosse o git bisect. Para iniciar a busca de um bug com o git bisect, usamos o seguinte comando: " git bisect start
Quando executamos o comando acima, o Git inicia o bisect para procurarmos o bug. Como o bug existe de 4 dias pra c, ento a nossa branch atual, a branch master, est com o bug e devemos marc-la como ruim, ou seja, bugada. Para isto, usamos o seguinte comando: " git bisect bad HEAD
O comando git bisect bad marca um commit como sendo ruim, ou seja, bugado. Conforme nosso usurio havia dito, h 4 dias atrs o bug no existia na pgina. Imagine que o commit com a hash <290fdfa9935512c0a945c72b50ed2925de66d0d6> tenha sido realizado h 4 dias atrs, ento pela lgica iremos marclo como bom, ou seja, no bugado, e fazemos isso com o comando: " git bisect good 290fdfa9935512c0a945c72b50ed2925de66d0d6
Quando executamos o comando acima, estamos dizendo ao Git que o commit com a hash informada est bom, ou seja, no est bugado. O Git, ento, ir automaticamente fazer o checkout de uma verso intermediria, entre a que marcamos como ruim e a que marcamos como bom, para testarmos. Se a verso que o Git fez o checkout automaticamente estiver com o bug, devemos marc-la como ruim, com o comando git bisect bad. Mas se a verso estiver sem o bug, devemos marc-la como boa, usando o comando git bisect good. O Git ir fazer chackouts automaticamente para testarmos at encontrar o commit em que o bug foi inserido. Veja, na Figura 99, todo o processo de busca do bug, usando o bisect:
Figura 99. Procurando um bug no repositrio usando o git bisect.
Todo checkout que o bisect nos retorna para testar, devemos marcar se ele est bom (good) ou ruim (bad), at o Git achar qual o commit em que foi inserido o bug. Fizemos isto no exemplo da Figura 99, e ao nal o Git nos informou exatamente o commit em que foi inserido o bug. Aps o Git nos informar em qual commit foi inserido o bug, devemos sair do modo bisect e usar o revert para corrigir este commit. Seguindo nosso exemplo, vamos ento sair do bisect com o comando: " git bisect reset
57
Figura 100. Saindo do modo bisect aps encontrado o commit com bug.
Veja, na Figura 100, que realmente o Git nos informou corretamente o commit que estava com bug. O fato comprovado na sada do git show, mostrando a tag do cabealho que foi invertida por um descuido do nosso programador. Agora que sabemos o commit em que foi inserido o bug, podemos iniciar o processo de revert do commit, conforme aprendemos anteriormente neste curso. #Fica a dica Para visualizarmos todas as alteraes realizadas em um commit, podemos usar o comando: " git show <HASH DO COMMIT>
5.5.1. Exerccio
Agora que voc aprendeu a procurar um bug, usando o git bisect, vamos colocar em prtica. 1. Altere o cabealho do arquivo pagina.html, deixando-o com o seguinte contedo: ... ! ... !
<h1>Git - O SCM feito da maneira correta!<\h1>
e faa o commit. (A tag de fechamento do cabealho deve car invertida, conforme escrito acima).
2. Altere novamente o arquivo pagina.html, adicionando um pargrafo com o seguinte contedo: ... ! ... !
<p><a href="http://www.git-scm.com/download">Link para download do Git</a></p>
e faa o commit.
3. Adicione mais um pargrafo no arquivo pagina.html, com o seguinte contedo: ... ! ...
<p><a href="http://www.git-scm.com/documentation">Link para documentacao do Git</a></p>
58
GIT - Controle de Verso com Rapidez e Segurana ! e faa o commit.
4. Novamente, adicione outro pargrafo no arquivo pagina.html, com o seguinte contedo: ... ! ... !
<p><a href="http://www.git-scm.com/about">Link para informacoes sobre o Git</a></p>
e faa o commit.
5. Aps realizar estas 4 alteraes, devemos procurar o bug que fez a pgina car desformatada, deixando todos os pargrafos com o mesmo estilo de um cabealho. Procure o bug na tag de cabecalho (<h1>) usando o git bisect. 6. Aps encontrar o bug, reverta o commit para corrig-lo.
5.6. Guardando alteraes para depois

Quando estamos trabalhando em um projeto de software comum termos que parar nosso trabalho para atender a uma nova solicitao. Imagine, por exemplo, que voc tenha trabalhado em vrias alteraes no cdigo mas seu chefe pede para fazer uma simples alterao no projeto. O que fazer com as alteraes que voc estava trabalhando? No podemos colocar essas alteraes em produo, pois ainda no esto completas, e por outro lado no queremos perd-las e ter que refazer tudo de novo. Para resolver este problema, o Git tem um recurso chamado git stash, que nos permite guardar nossas alteraes para us-las depois. Para exemplicar, vamos realizar uma alterao em nosso arquivo pagina.html, adicionando dois novos pargrafos: ... ! ! ...
<p>Com o Git podemos trabalhar desconectados</p> <p>O Git mantem todo o historico localmente</p>
Aps realizar as alteraes no working directory, uma nova prioridade surge, solicitando uma simples alterao no cabealho da pgina para o seguinte contedo: ... ! ...
<h1>Git - Um SCM moderno e poderoso!</h1>
A alterao solicitada dever ser feita urgentemente, mas as alteraes que estvamos trabalhando no podero ainda entrar em produo, pois no foram homologadas ou esto incompletas. Para realizar a alterao do cabealho sem perder nosso trabalho, usamos o seguinte comando: " git stash
Aps executar o stash, nossas alteraes sero guardadas para recuperarmos mais tarde. Agora podemos trabalhar normalmente na nova solicitao. Realizamos a alterao do cabealho, conforme solicitado, e efetuamos o commit. Agora que atendemos nova solicitao e realizamos o commit, podemos recuperar as alteraes que estvamos trabalhando, usando o comando: " git stash pop
59
GIT - Controle de Verso com Rapidez e Segurana #Fica a dica Podemos guardar vrias alteraes com o git stash, e para listar todos os stashs guardados usamos o comando: " git stash list
Por padro o comando git stash pop recupera o ltimo stash salvo, mas podemos recuperar algum outro stash salvo usando o nmero do stash conforme aparece na sada do comando git stash list.
5.6.1. Exerccio
Agora que voc aprendeu a usar o git stash para guardar alteraes para mais tarde, vamos colocar em prtica. 1. Altere o arquivo pagina.html, inserindo os seguintes pargrafos: ... ! ! ... !
<p>Com o Git podemos trabalhar desconectados</p> <p>O Git mantem todo o historico localmente</p>
mas NO faa o commit.
2. Guarde as alteraes com o git stash. 3. Altere o cabealho do arquivo pagina.html, deixando-o com o seguinte contedo: ... ! ... !
<h1>Git - Um SCM moderno e poderoso!</h1>
e faa o commit.
4. Recupere as alteraes de pargrafo, salvas pelo stash. 5. Faa o commit das alteraes de pargrafo recuperadas do stash.
60
6 - Ferramentas grficas do Git
Durante o curso, aprendemos como trabalhar com o Git atravs da linha de comando, que a forma padro, independente do Sistema Operacional. A vantagem de se trabalhar com a linha de comando que podemos usufruir de todos os recursos do Git. Mesmo assim, existem ferramentas grcas que facilitam o uso do Git, deixando sua usabilidade muito mais amigvel para aqueles que no gostam muito de trabalhar em linha de comando. Vamos indicar algumas destas ferramentas.
6.1. Ferramentas grcas para Mac

Para Mac, existem algumas opes para facilitar o uso do Git atravs de ferramentas grcas.
6.1.1. GitX
Uma das opes o GitX, uma interface gratuita e bastante simples que facilita o uso das funcionalidades bsicas do Git. Para baix-lo, basta acessar o link: http://gitx.frim.nl/index.html Veja algumas imagens do GitX em ao:
Figura 101. Log de commits de um repositrio do Git sendo visualizada no GitX.
Figura 102. Realizando um commit em um repositrio do Git atravs do GitX.
61
6.1.2. SmartGit
Outra ferramenta muito interessante para trabalhar com o Git em modo grco, no Mac, o SmartGit. Esta ferramenta vai alm do bsico do Git, oferecendo funcionalidades avanadas, como fazer um revert de um commit, sincronizar com repositrios remotos e inclusive interagir com o GitHub.com. O SmartGit, apesar de ser pago, possui uma verso gratuita para ns no comerciais. Para baix-lo, basta acessar o link: http://www.syntevo.com/smartgit/index.html Veja algumas imagens do SmartGit em ao:
Figura 103. Log de commits de um repositrio do Git sendo visualizado no SmartGit.
Figura 104. Realizando um commit em um repositrio do Git atravs do SmartGit.
6.1.3. Tower
O Tower uma das ferramentas grcas mais poderosas para usar o Git no Mac. Possui suporte a diversas funcionalidades avanadas do Git, como fazer o revert de um commit, sincronizar com repositrios remotos, sincronizar com o GitHub.com, trabalhar com stash, e muitas outras opes. O Tower uma ferramenta paga e possui uma verso trial para 30 dias de avaliao. Para baix-lo, basta acessar o link: http://www.git-tower.com
62
GIT - Controle de Verso com Rapidez e Segurana Veja algumas imagens do Tower em ao:
Figura 105. Visualizando o status da branch master em um repositrio do Git, atravs do Tower.
Figura 106. Log de commits de um repositrio do Git sendo visualizado no Tower.
6.2. Ferramentas grcas para Linux

Existem diversas ferramentas grcas para trabalhar com o Git no Linux. Dentre elas, as mais usadas so o Git Cola e o GitK.
63
6.2.1. Git Cola

Uma ferramenta grca muito interessante para usar o Git no Linux o Git Cola, com uma interface fcil de usar e atende bem s funcionalidades bsicas do Git, compreendendo tambm alguns recursos mais avanados. Para baix-lo, basta acessar o link: http://git-cola.github.com Veja algumas imagens do Git Cola em ao:
Figura 107. Realizando um commit em um repositrio do Git, atravs do Git Cola.
6.2.2. GitK
Outra opo para usar algumas funcionalidades bsicas do Git, em modo grco, o GitK. Veja uma imagem do GitK em ao:
Figura 108. Log de commits de um repositrio do Git sendo visualizado no GitK.
64
6.3. Ferramenta grca para Windows

No Windows, a mais completa ferramenta grca gratuita para trabalhar com o Git o TortoiseGit. O TortoiseGit tem uma interface amigvel e simples, e totalmente integrado ao Windows Explorer. Para baix-lo, basta acessar o link: " http://code.google.com/p/tortoisegit/downloads/list
Veja algumas imagens do TortoiseGit em ao:
Figura 109. Menu do TortoiseGit interagindo com um repositrio, no Windows Explorer.
Figura 110. Tela de commit do TortoiseGit.
65
Figura 111. Visualizando Logs de commit no TortoiseGit.
66
7 - Apndice
7.1. Montando um repositrio centralizado

Vimos durante o curso que o Git trabalha localmente, e vimos tambm que possvel sincronizar com repositrios remotos atravs da rede. Usar o GitHub para simular um servidor centralizado em projetos que usam o Git muito interessante, porm, em alguns casos, precisamos manter um repositrio centralizado e privado, onde apenas um grupo restrito de desenvolvedores tenham acesso a ele. Montar um repositrio centralizado com o Git simples. Alm do seu prprio protocolo, o Git tem suporte a outros protocolos para a comunicao entre repositrios. Veja alguns protocolos que o Git suporta: Git SSH HTTP(S) FTP(S) possvel ver a lista completa dos protocolos suportados pelo Git na pgina do manual do push, digitando o comando: " git help push
O Git no possui sistema de autenticao prprio, deixando esta competncia a cargo do protocolo de comunicao escolhido.Veremos como montar um repositrio centralizado com o Git no Mac, Linux e Windows.
7.1.1. Montando um repositrio centralizado no Mac e Linux

Iremos utilizar o protocolo SSH para a comunicao com o repositrio centralizado, j que o servidor SSH j vem instalado nativamente no Mac e na maioria das distribuies do Linux. Faremos isto em poucos passos: 1. Crie um usurio chamado git no servidor centralizado, denindo seu diretrio padro para /git, e dena sua senha; 2. Logue no servidor com o usurio git que voc criou; 3. Crie um diretrio chamado curso-git.git dentro do diretrio home (/git) denido para o usurio git; 4. No diretrio que voc criou (/git/curso-git.git), inicie um repositrio do Git com o comando: git init --bare
Figura 112. Criando um repositrio do Git no servidor centralizado.
67
GIT - Controle de Verso com Rapidez e Segurana 5. Adicione o repositrio remoto em seu repositrio local, usando o comando: " " git remote add central ssh://git@<IP DO SERVIDOR>/git/curso-git.git substituindo <IP DO SERVIDOR> pelo ip do seu servidor centralizado.
Figura 113. Adicionando o repositrio remoto centralizado em nosso repositrio local e fazendo a sincronizao entre os dois.
#Fica a dica Quando criamos um repositrio do Git que servir apenas de repositrio centralizado, iniciamos este repositrio com a ash --bare ao executar o git init: " git init --bare
Pronto! Agora nosso servidor centralizado est pronto e podemos sincronizar nosso repositrio local com ele atravs da rede, realizando push e pull.
7.1.2. Montando um repositrio centralizado no Windows

Montar um repositrio centralizado no Windows bastante simples. Para isto, siga os passos: 1. Em seu usurio do Windows, crie um diretrio que ser usado para armazenar os repositrios do Git, por exemplo: " c:\git;
2. Compartilhe o diretrio c:\git atravs do compartilhamento do windows (ative autenticao do compartilhamento do Windows para assegurar que todos se autentiquem para usar o repositrio); 3. Abra o prompt de comando, entre no diretrio c:\git que criamos: " cd c:\git
4. Inicie o repositrio remoto com o comando: " git init --bare
Pronto! Nosso repositrio remoto est criado. Para us-lo em outras mquinas Windows, basta montar o compartilhamento nestas mquinas e usar o repositrio localmente no diretrio que voc montou pela rede.
68
www.hachitecnologia.com.br

Apostila Git Hachi Tecnologia

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Apostila Git Hachi Tecnologia

Загружено:

Авторское право:

Доступные форматы

GIT - Controle de Verso com Rapidez e Segurana

Autor: Lucas Medeiros de Freitas Verso 1.12.4.6

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br

GIT - Controle de Verso com Rapidez e Segurana

3 - Iniciando com o Git!

GIT - Controle de Verso com Rapidez e Segurana

5 - Recursos avanados do Git!

GIT - Controle de Verso com Rapidez e Segurana

GIT - Controle de Verso com Rapidez e Segurana

5.6. Guardando alteraes para depois ! 5.6.1. Exerccio !

6 - Ferramentas grcas do Git!

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

GIT - Controle de Verso com Rapidez e Segurana

1 - Sistema de Controle de Verso, uma breve explicao

1.1 Controle de Verso

1.1.2. Como funciona?

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

GIT - Controle de Verso com Rapidez e Segurana

Figura 1. Funcionamento de um SCM. Fonte: Pronus Engenharia de Software

Figura 2. Esquema geral lgico de um SCM. Fonte: Wikipdia

1.2. Sistema de Controle de Verso Centralizado

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

Figura 3. Funcionamento de um SCM centralizado. Fonte: Pronus Engenharia de Software

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

GIT - Controle de Verso com Rapidez e Segurana

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

1.3. Sistema de Controle de Verso Distribudo

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

GIT - Controle de Verso com Rapidez e Segurana

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

GIT - Controle de Verso com Rapidez e Segurana

2.1. Git, um SCM rpido e seguro

2.2. Projetos que usam o Git

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

2.3. Com o Git, tudo local

2.4. O Git rpido

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

GIT - Controle de Verso com Rapidez e Segurana

2.5. O Git facilmente adaptvel ao seu uxo de trabalho

2.6. rea intermediria

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

GIT - Controle de Verso com Rapidez e Segurana

3 - Iniciando com o Git

3.1. Instalando o Git

3.1.1. Instalando o Git no Mac

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

Figura 24. Tela inicial do instalador do Git.

Clique em instalar para iniciar a instalao do Git.

Figura 25. Tela do instalador do Git.

Aps instalado, clique em Fechar para encerrar o instalador do Git.

Figura 26. Tela do instalador do Git.

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

3.1.2. Instalando o Git no Linux

3.1.3. Instalando o Git no Windows

Figura 27. Tela inicial do instalador do Git.

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!

Figura 28. Tela do instalador do Git.

Escolha o diretrio onde o Git dever ser instalado e clique em Next.

Figura 29. Tela do instalador do Git.

Na tela seguinte, deixe marcadas as opes padres e clique em Next.

Figura 30. Tela do instalador do Git.

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br!