Github

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
ndice
1 - Sistema de Controle de Verso, uma breve explicao
1.1 Controle de Verso
1
1
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
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
10
2.4. O Git rpido
10
2.5. O Git facilmente adaptvel ao seu fluxo de trabalho
11
2.6. rea intermediria
11
3 - Iniciando com o Git

3.1. Instalando o Git
12
12
3.1.1. Instalando o Git no Mac
12
3.1.2. Instalando o Git no Linux
14
3.1.2.1 Instalando o Git em distribuies que usam o YUM
14
3.1.2.2 Instalando o Git em distribuies que usam o APT-GET
14
3.1.2.3 Instalando o Git a partir do source
14
3.1.3. Instalando o Git no Windows

3.2. Configurando 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
4 - Trabalhando em Equipe
4.1. Hospedando nosso projeto no GitHub
14
17
17
17
18
18
20
22
22
4.1.1. Criando uma conta de usurio no GitHub
22
4.1.2. Criando um repositrio no GitHub
24
4.1.3. Enviando nossas alteraes ao repositrio do GitHub
26
4.1.4. Exerccio
27
4.2. Colaborando com o projeto
27
4.2.1. Adicionando um colaborador ao repositrio do GitHub
27
4.2.2. Realizando um clone do repositrio remoto
28
4.2.3. Enviando as alteraes ao repositrio remoto
30
4.2.4. Baixando as atualizaes do repositrio remoto
30
4.2.5. Resoluo manual de conflitos
31
4.2.6. Git blame, o famoso dedo-duro
33
4.2.7. Exerccio
33
5 - Recursos avanados do Git
34
5.1. Trabalhando com branches
34
5.1.1. Criando uma branch
34
5.1.2. Alternando entre branches
34
ii
5.1.3. Trabalhando com a nova branch
35
5.1.4. Enviando as alteraes para a branch master
39
5.1.5. Resolvendo conflitos no rebase
40
5.1.6. Enviando uma branch local para o repositrio remoto
44
5.1.7. Baixando uma branch do repositrio remoto para o repositrio local
45
5.1.8. Exerccio
45
5.2. Etiquetando nosso cdigo com tags
47
5.2.1. Criando uma tag
47
5.2.2. Exerccio
48
5.3. Usar o di faz toda a diferena
49
5.3.1. Mostrando as alteraes realizadas no working directory
49
5.3.2. Mostrando a diferena entre dois commits
49
5.3.3. Mostrando a diferena entre o commit atual e commits anteriores
50
5.3.4. Exerccio
50
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
50
51
52
52
53
53
54
54
55
56
58
iii
5.6. Guardando alteraes para depois

5.6.1. Exerccio
6 - Ferramentas grficas do Git

6.1. Ferramentas grficas para Mac
59
60
61
61
6.1.1. GitX
61
6.1.2. SmartGit
62
6.1.3. Tower
62
6.2. Ferramentas grficas para Linux
63
6.2.1. Git Cola
64
6.2.2. GitK
64
6.3. Ferramenta grfica para Windows
7 - Apndice
7.1. Montando um repositrio centralizado
65
67
67
7.1.1. Montando um repositrio centralizado no Mac e Linux
67
7.1.2. Montando um repositrio centralizado no Windows
68
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 especfica 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;
Identificar as alteraes feitas nos arquivos do projeto;
Trabalhar em equipe de forma simples e prtica;
Criar ramificaes 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 suficiente, 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 fica 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.

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.

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.
Aps obterem uma cpia do projeto, Aline e Roberto trabalham em suas alteraes. Ento Aline finaliza suas alterae e as
envia ao repositrio central atravs de um commit, como ilustra a Figura 5.
Figura 5. Ambos os desenvolvedores trabalham em modificaes no projeto, mas Aline publica suas alteraes primeiro.
Quando Roberto tenta enviar suas modificaes, o servidor as recusa e informa que seus arquivos esto desatualizados,
como ilustra a Figura 6.
Figura 6. Roberto envia suas modificaes logo aps Aline ter feito um commit, e ento o servidor recusa suas modificaes.
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.


Aps realizar o update, Roberto obtm as novas atualizaes do repositrio central. Agora Roberto poder enviar as
suas modificaes normalmente atravs de um commit.
Figura 8. Aps ter feito um update, Roberto estar apto a enviar suas modificaes atravs de um commit.
Enquanto Roberto est atualizando seu cdigo e enviando suas alteraes para o repositrio central, Aline trabalha em
novas modificaes 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 modificou.
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.
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.
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 fiel de todo o contedo sintrico e todo o histrico do projeto.

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 modificaes em seus repositrios locais, sem interferir no repositrio um do outro.
Mesmo possuindo um repositrio local, Roberto poder sincronizar seu repositrio com o de Aline, obtendo todas as
modificaes realizadas por ela, atravs de um comando pull.
Figura 14. Roberto baixa as atualizaes feitas por Aline, atravs de um comando pull.
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.
Depois de ter baixado as atualizaes de Aline, Roberto publica suas modificaes 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.


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.
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 suficiente 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 oficial 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;

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.
2.5. O Git facilmente adaptvel ao seu fluxo 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 fluxo de trabalho usando um repositrio central com o Git.
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 modificado na rea de trabalho.
Figura 21. rea intermediria do Git, uma grande vantagem em relao a outros SCMs.
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

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

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:

apt-get install git-core

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
Aps baixar o source do Git, basta descompact-lo e, em seu diretrio, executar os seguintes comandos (como root) para
instalar:

make prefix=/usr all
make prefix=/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

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

Na prxima tela, defina como deve aparecer o nome do Git no menu Iniciar do Windows. Deixe o padro, Git, e clique em
Next.
Na prxima tela, devemos definir 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

Uma mensagem de sucesso da instalao ir aparecer, aperte Finish!
3.2. Configurando o Git

Antes de comear a utilizar o Git, alguns ajustes precisam ser feitos. Precisamos definir o nome do nosso usurio e um email, que sero usados para identificar as alteraes que sero realizadas em nosso repositrio.
Para que esta configurao seja feita, as variveis globais user.name e user.email do Git precisam ser definidas.
3.2.1. Exerccio
Vamos configurar 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 config --global user.name <NOME DO SEU USURIO>
substituindo <NOME DO SEU USURIO> pelo nome de usurio que deseja utilizar.
2. Aps definir o usurio, ainda no terminal, defina o seu e-mail digitando o comando:

git config --global user.email <SEU ENDEREO DE EMAIL>
substituindo <SEU ENDEREO DE EMAIL> pelo seu endereo de e-mail.
3. Verifique as configuraes realizadas com o comando: git config -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

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 definimos 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 verificarmos 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 verificar que agora nosso arquivo pagina.html est trackeado, ou seja, ele est no
Index (staging area) e pronto para ser adicionado definitivamente no repositrio, em nossa branch master.
#Fica a dica
Uma branch uma ramificao 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 verificar o Log de commits com o comando git log:
Figura 40. Verificando 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 identificado por uma hash SHA-1 de 40 caracteres hexadecimais. Diferente de SCMs centralizados,
onde cada commit recebe um nmero como identificador (sendo que o commit mais recente sempre ter um
nmero maior que os anteriores), em SCMs distribudos, como o Git, cada commit identificado por uma hash
nica.
Sempre que executamos um commit, uma mensagem deve ser informada identificando-o. Veja na Figura 39 onde
executamos o comando git commit -m Criando nossa primeira pagina. A flag -m indica que o contedo em seguida
a mensagem do commit. Caso a flag -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

<html>

<head>

<title>Curso de Git</title>

</head>

<body>

<h1>Git - Um SCM rapido e seguro!</h1>

</body>
</html>
2. Salve o arquivo e verifique 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. Verifique o Log do commit realizado, com o comando git log.
7. Abra o arquivo pagina.html em seu browser e verifique 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

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 confirmao 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

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

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 configurar nosso repositrio remoto
curso-git em nosso repositrio local de mesmo nome para que seja feita a sincronizao entre os dois.
Para configurar 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 identific-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 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 fiel 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

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

Perceba na Figura 50 que adicionamos o usurio (vigarista-hachitecnologia) pertencente ao Dick Vigarista. Agora Dick
Vigarista est autorizado a realizar modificaes 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

O git status informa a Dick Vigarista que o arquivo pagina.html foi modificado 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 verifica 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 verificarmos 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:

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 conflitos

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 modificar a
mesma linha deste mesmo arquivo. Quando isto ocorre, o Git tenta aplicar o merge automtico mas falha, e a nica sada
resolver o conflito 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 conflito seja resolvido. Veja como ficou o
arquivo aps o conflito:
Figura 61. Contedo do arquivo pagina.html aps o conflito ocorrido ao executar o merge automtico.
Agora Dick Vigarista precisa resolver o conflito manualmente, decidindo qual contedo ir permanecer no ttulo da pgina.
Dick Vigarista resolve o conflito, deixando o ttulo com o seguinte contedo:

...

...
<title>Curso sobre o SCM Git</title>
Agora que Dick Vigarista editou o arquivo para resolver o conflito 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 modificao 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. Modifique o arquivo pagina.html adicionando um novo pargrafo, deixando-o com o seguinte contedo:
<html>

<head>


</head>

<body>


<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 ramificao do projeto, uma cpia paralela do projeto que nos permite realizar modificaes sem alterar
o projeto original. Trabalhar com branches (ramificaes) 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 exemplificar, 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.
Definimos 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 fizemos o commit destas alteraes. Perceba que as alteraes
foram commitadas apenas na branch desenvolvimento. Podemos verificar 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 refletiram 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 suficiente 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 modificaes que fizemos no foram feitas na
branch master, ficar fcil atender a essa nova solicitao.
Voltaremos para a branch master com o comando:

git checkout master
36

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>
Realizamos ento um commit com a correo do bug, gerando uma nova reviso.
Figura 70. Realizando um commit com a correo do bug.
37

#Fica a dica
Para adicionar as alteraes realizadas na staging area e commit-las ao mesmo tempo, podemos usar a flag -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 conflitos 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

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:

5.1.5. Resolvendo conflitos 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 conflito 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

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 conflito ocorre, gerando a seguinte sada:
Figura 78. Lucas Freitas realiza o rebase na branch master e percebe que ocorreram conflitos.
O Git informou que foi encontrado um conflito 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 conflito ocorre durante o
rebase, o Git cria uma branch temporria para que o conflito seja resolvido. Isto ocorrer em todos os commits que gerarem
41

conflito 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 conflitos do rebase.
No aviso do conflito, 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 conflitos manualmente, decidindo qual o contedo que dever ficar no arquivo pagina.html, e usar o
comando git rebase --continue aps resolver estes conflitos para dar continuidade ao rebase.
Veja o contedo do arquivo pagina.html aps o conflito:
Figura 80. Contedo do arquivo pagina.html com o conflito, aps o rebase.
O comando git status nos informa a mensagem both modified: pagina.html indicando que ambos os desenvolvedores
alteraram o mesmo arquivo, gerando um conflito. Devemos resolver o conflito para que esta mensagem desaparea.
Figura 81. Sada do comando git status informando que existe um conflito no arquivo pagina.html.
42

Optaremos por resolver o conflito manualmente, conforme aprendemos anteriormente no curso, decidindo ficar com o
contedo de Lucas Freitas para o pargrafo 1 da pgina. Alteramos ento o arquivo, para que ele fique com o seguinte
contedo:
Figura 82. Contedo do arquivo pagina.html aps resoluo do conflito gerado pelo rebase.
Aps resolver os conflitos manualmente, adicionamos o arquivo pagina.html ao Index, com o comando:

git add pagina.html
Verificando o status, percebemos que agora a mensagem both modified desapareceu, conforme Figura 83.
Figura 83. O status mostra que o conflito foi resolvido.
Aps ter resolvido todos os conflitos, podemos dar continuidade ao rebase com o comando:

git rebase --continue
Figura 84. Dando continuidade ao rebase, aps resolvidos os conflitos.
43

Agora que resolvemos os conflitos 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:
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

3. Aplique a folha de estilo (estilo.css) que criamos ao arquivo pagina.html, conforme cdigo abaixo:
...
<head>

<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:
...

...
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, modificando seu contedo de:
...

...
para
...

...
<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 especfica, ou ento para verificarmos uma particularidade no cdigo desta verso. No Git isto
possvel atravs das tags, que nos possibilita definir 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, verificando, 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 identificar 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 identificar a Verso 2.0 do nosso projeto.
Agora temos duas tags em nosso repositrio. Uma identificando a Verso 1.0 e outra identificando a Verso 2.0 do nosso
projeto. Caso seja necessrio voltar Verso 1.0, para verificar 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 verificar 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. Verificando a diferena entre as Verses 1.0 e 2.0 do nosso projeto, com o comando git diff.
Verifique 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 + significa 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

e realize o commit desta alterao.
3. Crie uma nova tag com a etiqueta v2.0.

4. Verifique 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 verificar 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 verificar 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 verificar a diferena entre um commit e outro, atravs da hash identificadora 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 verificar a diferena entre um commit anterior especfico em relao ao
commit atual. Vamos verificar 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. Verifique as diferenas realizadas no working directory e que ainda no foram commitadas.

3. Verifique a diferena entre dois commits quaisquer, realizados em sua branch master.
4. Verifique 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 verificar 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 verificamos 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 especfico, usando a sintaxe:

git checkout <HASH DO COMMIT>
51

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 exemplificar, 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 modificado 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

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

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 exemplificar, 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 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 oficial do Git, com o seguinte
contedo:
54

...

...

<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
fizemos 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 fizemos 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 ficou exatamente como estava no incio do projeto, com o seguinte contedo:
...

...
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

...
!

...


<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 exemplificar, 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, ficando: <\h1>.
56

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 final 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 ficar 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

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 ficar 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 exemplificar, 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

#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 grficas 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 grficas para Mac

Para Mac, existem algumas opes para facilitar o uso do Git atravs de ferramentas grficas.
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 grfico, 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 fins 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 grficas 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

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 grficas para Linux

Existem diversas ferramentas grficas 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 grfica 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 grfico, 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 grfica para Windows

No Windows, a mais completa ferramenta grfica 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, definindo seu diretrio padro para /git, e defina 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) definido 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

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 flash --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

Github

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Github

Enviado por

Direitos autorais:

Formatos disponíveis

GIT - Controle de Verso com

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br

GIT - Controle de Verso com Rapidez e Segurana

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

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 fluxo de trabalho

2.6. rea intermediria

3 - Iniciando com 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

GIT - Controle de Verso com Rapidez e Segurana

3.1.3. Instalando o Git no Windows

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.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 conflitos

4.2.6. Git blame, o famoso dedo-duro

5 - Recursos avanados do Git

5.1. Trabalhando com branches

5.1.1. Criando uma branch

5.1.2. Alternando entre branches

2012 Hachi Tecnologia | treinamento@hachitecnologia.com.br

GIT - Controle de Verso com Rapidez e Segurana

5.1.3. Trabalhando com a nova branch

5.1.4. Enviando as alteraes para a branch master

5.1.5. Resolvendo conflitos 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.2. Etiquetando nosso cdigo com tags

5.2.1. Criando uma tag

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.4. Desfazendo alteraes

GIT - Controle de Verso com Rapidez e Segurana

5.6. Guardando alteraes para depois

6 - Ferramentas grficas do Git

6.2. Ferramentas grficas para Linux

6.2.1. Git Cola

6.3. Ferramenta grfica para Windows

7.1.1. Montando um repositrio centralizado no Mac e Linux

7.1.2. Montando um repositrio centralizado no Windows

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