Controlando Versões Com Git e GitHub - Casa Do Codigo
Controlando Versões Com Git e GitHub - Casa Do Codigo
Controlando Versões Com Git e GitHub - Casa Do Codigo
Casa do Código
Livros para o programador
Rua Vergueiro, 3185 - 8º andar
04101-300 – Vila Mariana – São Paulo – SP – Brasil
Casa do Código Sumário
Sumário
1 Introdução 1
1.1 Mantendo o histórico do código . . . . . . . . . . . . . . . . . 1
1.2 Trabalhando em equipe . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Sistemas de controle de versão . . . . . . . . . . . . . . . . . . 2
1.4 Controle de versão rápido e confiável com Git . . . . . . . . . 3
1.5 Hospedando código no GitHub . . . . . . . . . . . . . . . . . 3
1.6 O processo de escrita desse livro . . . . . . . . . . . . . . . . . 4
2 Tour prático 5
2.1 Instalando e configurando o Git . . . . . . . . . . . . . . . . . 5
2.2 Criando um arquivo texto para versionarmos . . . . . . . . . 7
2.3 Versionando seu código com Git . . . . . . . . . . . . . . . . 8
2.4 Compartilhando seu código através do GitHub . . . . . . . . 12
i
Sumário Casa do Código
ii
Casa do Código Sumário
iii
Capítulo 1
Introdução
1.1 Mantendo o histórico do código
Vida de programador não é fácil. Há sempre uma pressão por entregas rápidas
de novas funcionalidades. Mas, apesar da pressa, é necessário prestar atenção
no que estamos fazendo, mesmo se a alteração for pequena. Ao mexermos
em um código existente é importante tomarmos cuidado para não quebrar o
que já funciona.
Por isso, queremos mexer o mínimo possível no código. Temos medo
de remover código obsoleto, não utilizado ou até mesmo comentado, mesmo
que mantê-lo já nem faça sentido. Não é incomum no mercado vermos código
funcional acompanhado de centenas de linhas de código comentado.
Sem dúvida, é interessante manter o histórico do código dos projetos,
para entendermos como chegamos até ali. Mas manter esse histórico junto
ao código atual, com o decorrer do tempo, deixa nossos projetos confusos,
1.2. Trabalhando em equipe Casa do Código
poluídos com trechos e comentários que poderiam ser excluídos sem afetar o
funcionamento do sistema.
Seria bom se houvesse uma maneira de navegarmos pelo código do pas-
sado, como uma máquina do tempo para código...
2
Casa do Código Capítulo 1. Introdução
3
1.6. O processo de escrita desse livro Casa do Código
4
Capítulo 2
Tour prático
Neste capítulo, faremos um tour bem prático sobre como usar o Git para ver-
sionar nossos projetos. Não se preocupe com o significado dos comandos.
No decorrer do livro, todos os comandos usados aqui serão explicados com
profundidade.
Instalando no Windows
Acesse a seguinte URL, faça o download e instale a última versão dispo-
nível: http://msysgit.github.io/
2.1. Instalando e configurando o Git Casa do Código
Esse prompt será seu amigo a partir de agora. Não tenha medo! Sempre
que falarmos de terminal, estaremos falando do Git Bash.
Instalando no Mac
Baixe a última versão do instalador gráfico do Git para Mac OS X a partir
do link: https://code.google.com/p/git-osx-installer/downloads
Abra um terminal e prepare-se para utilizar o Git!
Instalando no Linux
Para instalar o Git no Ubuntu, ou em uma outra distribuição baseada em
Debian, execute em um terminal:
No Fedora, utilize:
Configurações básicas
É importante nos identificarmos para o Git, informando nosso nome e
e-mail. Em um terminal, execute os comandos a seguir:
6
Casa do Código Capítulo 2. Tour prático
A linha de comando
7
2.3. Versionando seu código com Git Casa do Código
Pasta pessoal
$ echo ~
Criando um repositório
Abra um terminal e vá até o diretório citacoes.
$ cd ~/citacoes
$ git init
8
Casa do Código Capítulo 2. Tour prático
Rastreando o arquivo
Mas e o arquivo filmes.txt? Será que já está versionado?
Podemos ver a situação dos arquivos no repositório Git com o comando:
git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be
committed)
#
# filmes.txt
nothing added to commit but untracked files present (use
"git add" to track)
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: filmes.txt
#
9
2.3. Versionando seu código com Git Casa do Código
Alterando o arquivo
Insira mais uma linha no arquivo filmes.txt, com o conteúdo:
"Hasta la vista, baby." (Exterminador do Futuro 2)
10
Casa do Código Capítulo 2. Tour prático
$ git log
commit 7878787000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Fri Apr 11 21:21:31 2014 -0300
commit 8666888000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Fri Apr 11 21:21:31 2014 -0300
11
2.4. Compartilhando seu código através do GitHub Casa do Código
12
Casa do Código Capítulo 2. Tour prático
13
2.4. Compartilhando seu código através do GitHub Casa do Código
14
Casa do Código Capítulo 2. Tour prático
15
2.4. Compartilhando seu código através do GitHub Casa do Código
Observe que o arquivo que você enviou já está disponível para qualquer
pessoa da internet. Avise seu primo, sua vizinha, todo mundo!
É possível ver todas as alterações no projeto até agora (no caso, fo-
ram duas), através do endereço: https://github.com/fulanodasilva/citacoes/
commits/master
16
Casa do Código Capítulo 2. Tour prático
$ cd ~/projetos_git
17
2.4. Compartilhando seu código através do GitHub Casa do Código
$ cd citacoes
$ git log
commit 7878787000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Fri Apr 11 21:21:31 2014 -0300
commit 8666888000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Fri Apr 11 21:21:31 2014 -0300
18
Capítulo 3
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="description" content="Móveis ecológicos">
<meta name="keywords" content="moveis ecologicos">
</head>
<body>
<h1>Móveis Ecológicos S. A.</h1>
<ul>
<li>Móveis de garrafas PET</li>
<li>Móveis de latinhas de alumínio</li>
<li>Móveis de papelão</li>
</ul>
</body>
</html>
20
Casa do Código Capítulo 3. Trabalhando com repositório local
$ git init
Teremos a saída:
total 36K
drwxr-xr-x 3 fulano fulano 4,0K Abr 15 21:30 .
drwx------ 58 fulano fulano 16K Abr 15 21:27 ..
drwxr-xr-x 7 fulano fulano 4,0K Abr 15 21:30 .git
-rw-r--r-- 1 fulano fulano 405 Abr 15 21:27 index.html
Basta o comando git init para criar um repositório com Git, que
já cria localmente um repositório completo. Isso é bem mais simples que
diversos outros sistemas de controle de versão, como o SVN, que preci-
savam da configuração de um servidor.
21
3.2. Rastreando arquivos Casa do Código
Note que o arquivo index.html ainda não está sendo rastreado (está
em Untracked files).
Para informar ao Git que o arquivo index.html deve ser rastreado, uti-
lizamos o comando:
$ git add index.html
22
Casa do Código Capítulo 3. Trabalhando com repositório local
h1 {
font-family: sans-serif;
}
li {
font-family: monospace;
}
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: index.html
#
# Untracked files:
# (use "git add <file>..." to include in what will be
committed)
#
# estilos.css
# imagens/
23
3.2. Rastreando arquivos Casa do Código
$ git add .
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: estilos.css
# new file: imagens/logo.png
# new file: index.html
#
A área de stage
Quando informamos para o Git que queremos rastrear um arquivo, exe-
cutando git add pela primeira vez, o Git coloca esse arquivo em uma área
especial do repositório, chamada de stage.
Uma vez que um arquivo está na área de stage, todas as mudanças nesse
arquivo passam a ser examinadas.
24
Casa do Código Capítulo 3. Trabalhando com repositório local
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: estilos.css
# new file: imagens/logo.png
# new file: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in
working directory)
#
# modified: index.html
#
25
3.2. Rastreando arquivos Casa do Código
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: estilos.css
# new file: imagens/logo.png
# new file: index.html
#
26
Casa do Código Capítulo 3. Trabalhando com repositório local
Ignorando arquivos
Suponha que temos um arquivo todo.txt que mantemos, durante o
desenvolvimento, com a lista das tarefas do dia. Suponha também que temos
um subdiretório chamado tmp, com alguns arquivos temporários gerados ao
manipularmos imagens. Não faz sentido manter o histórico de ambos no Git.
Se executarmos git status, o arquivo todo.txt e o subdiretório
tmp serão mostrados como arquivos ainda não rastreados:
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: estilos.css
# new file: imagens/logo.png
# new file: index.html
#
# Untracked files:
# (use "git add <file>..." to include in what will be
committed)
#
# tmp/
# todo.txt
Será que teremos sempre que lembrar de evitar o git add desses ar-
quivos? Se for assim, não poderemos mais utilizar git add ., já que esse
comando rastreia todos os arquivos.
Para resolver isso, o Git tem um mecanismo que permite ignorarmos ar-
quivos. Basta criarmos um arquivo chamado .gitignore no diretório prin-
cipal do nosso projeto, com os nomes dos arquivos que queremos ignorar.
No nosso caso, devemos criar um arquivo chamado .gitignore no
diretório moveis, com o seguinte conteúdo:
todo.txt
tmp/
27
3.2. Rastreando arquivos Casa do Código
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: estilos.css
# new file: imagens/logo.png
# new file: index.html
#
# Untracked files:
# (use "git add <file>..." to include in what will be
committed)
#
# .gitignore
28
Casa do Código Capítulo 3. Trabalhando com repositório local
29
3.3. Gravando arquivos no repositório Casa do Código
# On branch master
nothing to commit, working directory clean
30
Casa do Código Capítulo 3. Trabalhando com repositório local
body {
width: 50%;
margin: auto;
}
/* resto do css */
31
3.3. Gravando arquivos no repositório Casa do Código
# On branch master
nothing to commit, working directory clean
var banners =
["Os melhores do Brasil!", "Qualidade e preço baixo!"];
var bannerAtual = 0;
function trocaBanner() {
bannerAtual = (bannerAtual + 1) % 2;
document.querySelector(’h2#mensagem’).textContent =
banners[bannerAtual];
}
setInterval(trocaBanner, 2000);
32
Casa do Código Capítulo 3. Trabalhando com repositório local
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: index.html
#
# Untracked files:
# (use "git add <file>..." to include in what will be
committed)
#
# principal.js
no changes added to commit (use "git add" and/or
"git commit -a")
Na saída, teremos:
33
3.3. Gravando arquivos no repositório Casa do Código
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be
committed)
#
# principal.js
nothing added to commit but untracked files present (use
"git add" to track)
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: principal.js
#
34
Casa do Código Capítulo 3. Trabalhando com repositório local
# On branch master
nothing to commit, working directory clean
35
3.4. Verificando o histórico do seu repositório Casa do Código
$ git log
commit 222cccc000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Wed Apr 30 21:21:31 2014 -0300
commit 9222999000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Wed Apr 30 21:21:33 2014 -0300
commit 2299922000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Wed Apr 30 14:02:26 2014 -0300
commit 7777444000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Tue Apr 29 21:21:31 2014 -0300
Commit inicial
36
Casa do Código Capítulo 3. Trabalhando com repositório local
$ git log -n 2
commit 222cccc000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Wed Apr 30 21:21:31 2014 -0300
commit 9222999000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Wed Apr 30 21:21:33 2014 -0300
37
3.4. Verificando o histórico do seu repositório Casa do Código
commit 222cccc000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Wed Apr 30 21:21:31 2014 -0300
principal.js | 10 ++++++++++
1 file changed, 10 insertions(+)
commit 9222999000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Wed Apr 30 21:21:33 2014 -0300
index.html | 2 ++
1 file changed, 2 insertions(+)
commit 2299922000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Wed Apr 30 14:02:26 2014 -0300
estilos.css | 4 ++++
index.html | 1 +
2 files changed, 5 insertions(+)
commit 7777444000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Tue Apr 29 21:21:31 2014 -0300
Commit inicial
38
Casa do Código Capítulo 3. Trabalhando com repositório local
.gitignore | 3 +++
estilos.css | 6 ++++++
imagens/logo.png | Bin 0 -> 15555 bytes
index.html | 20 ++++++++++++++++++++
4 files changed, 29 insertions(+)
(END)
39
3.5. Verificando mudanças nos arquivos rastreados Casa do Código
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: index.html
#
no changes added to commit (use "git add" and/or
"git commit -a")
$ git diff
40
Casa do Código Capítulo 3. Trabalhando com repositório local
O git diff não poderá ser utilizado para arquivos novos, que ainda
não estão sendo rastreados pelo Git (ou seja, que ainda não tiveram o
primeiro git add executado).
Será exibida uma saída exatamente igual à anterior, já que a alteração ape-
nas passou para a área de stage mas continua a mesma:
41
3.5. Verificando mudanças nos arquivos rastreados Casa do Código
<title>Móveis Ecológicos</title>
<script src="principal.js"></script>
</head>
- <body>
+ <body > <h1>Móveis Ecológicos S. A.</h1>
<h2 id="mensagem"></h2>
//inicio do arquivo...
setInterval(trocaBanner, 1000);
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: principal.js
#
42
Casa do Código Capítulo 3. Trabalhando com repositório local
-setInterval(trocaBanner, 2000);
+setInterval(trocaBanner, 1000);
43
3.5. Verificando mudanças nos arquivos rastreados Casa do Código
</head>
- <body>
+ <body > <h1>Móveis Ecológicos S. A.</h1>
<h2 id="mensagem"></h2>
diff --git a/principal.js b/principal.js
index 9999988..0000000 100111
--- a/principal.js
+++ b/principal.js
@@ -6,5 +6,5 @@ function trocaBanner() {
document.querySelector(’h2#mensagem’).textContent =
banners[bannerAtual];
}
-setInterval(trocaBanner, 2000);
+setInterval(trocaBanner, 1000);
:
44
Casa do Código Capítulo 3. Trabalhando com repositório local
45
3.5. Verificando mudanças nos arquivos rastreados Casa do Código
-setInterval(trocaBanner, 2000);
+setInterval(trocaBanner, 1000);
:
46
Casa do Código Capítulo 3. Trabalhando com repositório local
<html>
<body>
<ul>
<li>Móveis de garrafas PET</li>
<li>Móveis de latinhas de alumínio</li>
<li>Móveis de papelão</li>
</ul>
</body>
</html>
$ git rm produtos.html
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# deleted: produtos.html
#
47
3.6. Removendo arquivos do repositório Casa do Código
48
Casa do Código Capítulo 3. Trabalhando com repositório local
Renomeando arquivos
Para manter o padrão de nomenclatura, resolvemos modificar o nome do ar-
quivo estilos.css para principal.css.
Para fazer isso, teríamos que criar o novo arquivo, copiar seu conteúdo,
remover o arquivo antigo, adicionando tanto o novo arquivo como a deleção
do arquivo antigo na área de stage.
Bastante trabalho, não? Ainda bem que esse trabalho todo pode ser pou-
pado com o comando:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# renamed: estilos.css -> principal.css
#
49
3.7. Renomeando e movendo arquivos Casa do Código
Movendo arquivos
E se quisermos mover o arquivo principal.js para um subdiretório
chamado js?
Primeiramente, devemos criar o diretório js.
Depois, deveríamos criar um arquivo principal.js dentro desse novo
diretório, copiar os conteúdos do arquivo anterior e adicionar o novo diretó-
rio à área de stage. Feito isso, precisaríamos remover o arquivo atual, adicio-
nando a remoção à stage. Só então poderíamos comitar as alterações.
Todo esse trabalho também pode ser poupado pelo comando git mv:
$ git mv principal.js js/principal.js
50
Casa do Código Capítulo 3. Trabalhando com repositório local
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# renamed: principal.js -> js/principal.js
#
51
3.8. Desfazendo mudanças Casa do Código
52
Casa do Código Capítulo 3. Trabalhando com repositório local
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: index.html
#
no changes added to commit (use "git add" and/or
"git commit -a")
# On branch master
nothing to commit, working directory clean
53
3.8. Desfazendo mudanças Casa do Código
# On branch master
# Changes not staged for commit:
# (use "git add/rm <file>..."to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# deleted: index.html
#
no changes added to commit (use "git add" and/or
"git commit -a")
54
Casa do Código Capítulo 3. Trabalhando com repositório local
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
#
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: index.html
#
no changes added to commit (use "git add" and/or
"git commit -a")
55
3.8. Desfazendo mudanças Casa do Código
# On branch master
nothing to commit, working directory clean
56
Casa do Código Capítulo 3. Trabalhando com repositório local
Note que o comando git revert efetuou um novo commit com a ver-
são anterior dos arquivos. Foi utilizada a mensagem Revert seguida da men-
sagem do commit anterior (no exemplo, Revert “Adicionando texto peculiar”).
57
3.8. Desfazendo mudanças Casa do Código
58
Casa do Código Capítulo 3. Trabalhando com repositório local
59
Capítulo 4
O parâmetro --bare serve para que o Git não crie um working tree (dire-
tório de trabalho), impedindo que commits sejam efetuados diretamente no
servidor. No nosso caso faz sentido, já que os commits serão realizados pelos
62
Casa do Código Capítulo 4. Trabalhando com repositório remoto
63
4.2. Adicionando o repositório remoto Casa do Código
$ git remote
servidor
Mas repare que é exibido apenas o name dos repositórios remotos. Para
que também seja exibida a url devemos adicionar o parâmetro -v ao co-
mando:
$ git remote -v
servidor file://192.168.1.1/opt/repositorios/
moveis-ecologicos.git (fetch)
servidor file://192.168.1.1/opt/repositorios/
moveis-ecologicos.git (push)
Observe que o repositório remoto foi listado duas vezes. Isso acontece
pois o Git permite que tenhamos duas URLs distintas para o mesmo reposi-
tório remoto, sendo uma para leitura (fetch) e outra para escrita (push). Isto
pode ser útil se precisarmos utilizar protocolos distintos para leitura e escrita.
64
Casa do Código Capítulo 4. Trabalhando com repositório remoto
$ git remote -v
servidor file://192.168.1.1/opt/repositorios/
moveis-ecologicos.git (fetch)
servidor file://192.168.1.1/opt/repositorios/
moveis-ecologicos.git (push)
$ git remote -v
servidor file://192.168.1.2/opt/repositorios/
moveis-ecologicos.git (fetch)
servidor file://192.168.1.2/opt/repositorios/
moveis-ecologicos.git (push)
65
4.4. Clonando o repositório remoto Casa do Código
66
Casa do Código Capítulo 4. Trabalhando com repositório remoto
67
4.6. Protocolos suportados pelo Git Casa do Código
• Local
• SSH
• Git
• HTTP/HTTPS
Protocolo local
O protocolo local foi o utilizado neste capítulo. Ele pode ser utilizado
quando o repositório remoto estiver localizado no mesmo computador em
68
Casa do Código Capítulo 4. Trabalhando com repositório remoto
Protocolo SSH
O protocolo SSH é, provavelmente, o mais utilizado, por ser rápido, se-
guro, simples de configurar e por suportar tanto a leitura quanto a escrita de
dados.
O uso do protocolo SSH é feito com a URL seguindo o padrão
usuario@servidor:/caminho/repositorio.git. Por exemplo:
Protocolo Git
O Git possui um protocolo próprio, que é similar ao SSH, mas sem o me-
canismo de autenticação. Por conta disso, ele acaba sendo mais rápido; entre-
tanto não é seguro, e seu uso é apenas para leitura.
Para clonar um repositório utilizando o protocolo Git, a URL deve possuir
o prefixo git://:
69
4.6. Protocolos suportados pelo Git Casa do Código
Protocolo HTTP/HTTPS
O Git também suporta o protocolo HTTP, que é bastante utilizado
quando estamos trabalhando em empresas que possuem um controle rígido
de segurança, e a porta 22, utilizada pelo protocolo SSH, é bloqueada.
Para clonar um repositório utilizando o protocolo HTTP, a URL deve pos-
suir o prefixo http://:
70
Capítulo 5
Hospedando o repositório no
GitHub
No capítulo anterior, vimos como utilizar um repositório remoto, para que
tenhamos facilidade ao trabalhar em equipe no projeto. Agora, sempre que
um novo membro da equipe for trabalhar no projeto, ele deve primeiramente
clonar o repositório, efetuar as alterações necessárias, comitar tais alterações,
e então enviar os commits para o repositório remoto.
Assim sendo, vimos que a utilização de um repositório remoto nos ajuda
a ter uma melhor organização para trabalhar em equipe em um projeto, além
de também funcionar como backup.
Entretanto, como o repositório remoto está localizado em um servidor
da empresa, ficamos limitados a efetuar a sincronização apenas dentro dela,
pois precisaremos estar conectados à rede local para conseguirmos acessar o
5.1. Serviços de hospedagem de projetos Casa do Código
servidor.
Se algum dia um desenvolvedor precisar sincronizar as alterações com o
repositório remoto de fora da empresa, por exemplo de casa, isso não vai ser
possível, pois ele não vai estar conectado à rede local.
Até é possível acessar a rede local da empresa externamente, mas para
isso será necessário configurar uma VPN (Virtual Private Network), ou liberar
acesso externo ao servidor via SSH, o que pode ser algo complicado de se
fazer, além de também poder ser proibido por algumas empresas, devido a
políticas de segurança.
O ideal seria que o repositório remoto estivesse acessível pela internet,
pois assim poderíamos acessá-lo de qualquer lugar do mundo, bastando ape-
nas estarmos conectados à internet.
• GitHub
• Bitbucket
• Google Code
72
Casa do Código Capítulo 5. Hospedando o repositório no GitHub
• jQuery
• Ruby on Rails
• Node.js
• Django
• Bootstrap
• Pull Requests: para que outros usuários possam enviar seus commits
com alterações no projeto, ou commits com correções de bugs;
73
5.3. Encontrando projetos e visualizando o código-fonte Casa do Código
vão trabalhar. Isso é muito útil para empresas que possuem muitos projetos e
muitos colaboradores, pois permite uma melhor organização.
Por conta dessas funcionalidades e por permitir uma maior colaboração
nos repositórios, o GitHub é considerado por muitos como uma espécie de
rede social para desenvolvedores.
74
Casa do Código Capítulo 5. Hospedando o repositório no GitHub
75
5.3. Encontrando projetos e visualizando o código-fonte Casa do Código
76
Casa do Código Capítulo 5. Hospedando o repositório no GitHub
projeto, onde também é possível navegar por commits mais antigos. Visuali-
zar esta página seria como executar o comando git log no repositório.
77
5.3. Encontrando projetos e visualizando o código-fonte Casa do Código
78
Casa do Código Capítulo 5. Hospedando o repositório no GitHub
79
5.4. Criando um usuário no GitHub Casa do Código
80
Casa do Código Capítulo 5. Hospedando o repositório no GitHub
81
5.4. Criando um usuário no GitHub Casa do Código
82
Casa do Código Capítulo 5. Hospedando o repositório no GitHub
vados que poderão ser criados. No plano mais barato, que atualmente custa
$7 por mês, é possível criar até 5 repositórios privados, enquanto que no plano
mais caro, que atualmente custa $50 por mês, essa quantidade de repositórios
privados sobe para 50.
Após escolher o plano que mais se adeque às nossas necessidades, deve-
mos finalizar o cadastro clicando no botão Finish sign up, e seremos redire-
cionados para a página que mostra os repositórios do nosso usuário e outras
informações. Essa página é conhecida como Dashboard.
83
5.5. Criando o repositório do projeto Casa do Código
84
Casa do Código Capítulo 5. Hospedando o repositório no GitHub
85
5.7. Clonando o repositório hospedado no GitHub Casa do Código
Após o Git enviar os commits para o repositório remoto, será exibida uma
mensagem como:
86
Casa do Código Capítulo 5. Hospedando o repositório no GitHub
87
5.8. Colaborando com projetos open source Casa do Código
88
Casa do Código Capítulo 5. Hospedando o repositório no GitHub
Pull requests
A solução do GitHub para a colaboração com projetos open source, foi
uma funcionalidade chamada de pull requests.
Primeiramente, devemos acessar a página do projeto que queremos cola-
borar no GitHub, no nosso caso http://github.com/caelum/vraptor4, e clicar
no botão Fork:
89
5.8. Colaborando com projetos open source Casa do Código
Figura 5.22: Página com botão para criar um novo Pull request
90
Casa do Código Capítulo 5. Hospedando o repositório no GitHub
Figura 5.23: Página com botão para confirmar a criação do pull request
91
Capítulo 6
$ git branch
* master
Peraí! Foi mostrada uma branch chamada master, mesmo sem termos
criados nenhuma branch... Isso ocorreu porque o Git possui por padrão uma
branch principal chamada master. Todos os nossos commits até agora ocor-
reram nessa branch principal.
94
Casa do Código Capítulo 6. Organizando o trabalho com branches
Observe que a branch master tem um asterisco (*) na frente. Isso indica
que é a branch atual, em que estamos trabalhando.
No Git, toda branch é basicamente um apontador para um commit. A
cada novo commit que fazemos, a branch é movida automaticamente, pas-
sando a apontar para esse novo commit. Por isso, por padrão, a branch
master aponta para o último commit que fizemos.
Se quisermos listar as branches existentes no nosso repositório com os
commits associados, poderíamos utilizar a opção -v do comando git
branch:
$ git branch -v
95
6.2. Criando uma branch Casa do Código
96
Casa do Código Capítulo 6. Organizando o trabalho com branches
design
* master
97
6.3. Trocando de branch Casa do Código
Observe que o asterisco (*) que indica a branch atual foi mudada para a
branch design. Ambas as branches continuam apontando para o mesmo
commit.
Visualizando o estado do nosso repositório, teríamos:
98
Casa do Código Capítulo 6. Organizando o trabalho com branches
Note que o asterisco (*) está na branch loja, indicando que essa é a
branch atual. E a loja foi criada apontando para o commit b92285b, o
mesmo das outras branches.
99
6.4. Deletando uma branch Casa do Código
Não é possível deletar com a opção -d uma branch que possui commits
ainda não aplicados em outras branches (veremos como mesclar branches
mais adiante).
Para removermos a branch loja se tivermos feito algum commit, deve-
mos utilizar a opção -D:
Teríamos na saída:
100
Casa do Código Capítulo 6. Organizando o trabalho com branches
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="description" content="Móveis ecológicos">
<meta name="keywords" content="moveis ecologicos">
<link rel="stylesheet"
href="http://netdna.bootstrapcdn.com/bootstrap/3.1.1/
css/bootstrap.min.css">
<title>Móveis Ecológicos</title>
<script src="js/principal.js"></script>
</head>
<body > <div class="container">
<div class="jumbotron">
<h1>Móveis Ecológicos S. A.</h1>
<h2 id="mensagem"></h2>
<ul class="list-group">
<li class="list-group-item">
Móveis de garrafas PET
</li>
<li class="list-group-item">
Móveis de latinhas de alumínio
</li>
<li class="list-group-item">
Móveis de papelão
</li>
</ul>
</div>
</div>
101
6.5. Comitando código em uma nova branch Casa do Código
</body>
</html>
Também vamos remover o nosso CSS antigo, para não ficarmos com có-
digo obsoleto, executando o comando git rm principal.css.
Agora, vamos adicionar à área de stage as alterações e comitá-las com o
comando git commit -am "Adicionando Bootstrap".
Na saída, será impresso:
102
Casa do Código Capítulo 6. Organizando o trabalho com branches
103
6.6. Voltando para o master e fazendo uma alteração Casa do Código
104
Casa do Código Capítulo 6. Organizando o trabalho com branches
Note que a branch master está apontando para o commit 2223859 que
acabamos de realizar. Já a branch design continua apontando para o mesmo
commit que estava anteriormente.
Poderíamos então publicar com rapidez os novos banners sem as modi-
ficações de design, que ainda não foram aprovadas.
105
6.7. Mesclando alterações Casa do Código
design
* master
Removing principal.css
Merge made by the ’recursive’ strategy.
index.html | 31 +++++++++++++++++++++++--------
principal.css | 11 -----------
2 files changed, 23 insertions(+), 19 deletions(-)
delete mode 100111 principal.css
106
Casa do Código Capítulo 6. Organizando o trabalho com branches
107
6.7. Mesclando alterações Casa do Código
108
Casa do Código Capítulo 6. Organizando o trabalho com branches
109
6.7. Mesclando alterações Casa do Código
110
Casa do Código Capítulo 6. Organizando o trabalho com branches
111
6.7. Mesclando alterações Casa do Código
Para isso, o Git precisa criar novos commits, mudando os ancestrais de com-
mits anteriores.
Com a base da branch design refeita, é possível fazer um merge do tipo
fast-forward da design na branch master. Para tal, deveríamos ir para
a master executando git checkout master. Então, faríamos um git
merge design. O gráfico do repositório ficaria parecido com:
112
Capítulo 7
(fetch)
origin git@github.com:fulanodasilva/moveis-ecologicos.git
(push)
$ git branch -r
Teremos na saída:
origin/master
114
Casa do Código Capítulo 7. Trabalhando em equipe com branches remotas
$ git branch -r -v
Teremos:
Figura 7.1: O repositório do GitHub não contém a branch design, apenas a sua
master
115
7.2. Compartilhando branches Casa do Código
Figura 7.2: Repositório local tem as branches locais master e design e a remota
origin/master
116
Casa do Código Capítulo 7. Trabalhando em equipe com branches remotas
117
7.3. Obtendo novas branches remotas em outros repositórios Casa do Código
118
Casa do Código Capítulo 7. Trabalhando em equipe com branches remotas
119
7.3. Obtendo novas branches remotas em outros repositórios Casa do Código
Uma outra maneira, mais sucinta, de criar uma tracking branch é uti-
lizar a opção -t do comando git checkout.
No nosso caso, faríamos git checkout -t origin/design.
Seria criada localmente a tracking branch design relacionada com a
branch remota origin/design.
120
Casa do Código Capítulo 7. Trabalhando em equipe com branches remotas
121
7.4. Enviando commits para o repositório central Casa do Código
122
Casa do Código Capítulo 7. Trabalhando em equipe com branches remotas
Um novo commit
Digamos que outro desenvolvedor da nossa equipe esteja trabalhando em
uma página que lista móveis feitos a partir de garrafas PET. Todo trabalho
está sendo feito diretamente na branch master.
Para simular esse outro desenvolvedor, vamos utilizar nosso repositó-
rio outro. Retornaremos a esse repositório, executando o comando cd
~/outro.
Então, vamos nos certificar que estamos na branch master, executando
git checkout master.
Feito isso, vamos criar um arquivo moveis_pet.html com o seguinte
conteúdo:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="description"
content="Móveis ecológicos PET">
123
7.5. Obtendo commits de uma branch remota Casa do Código
124
Casa do Código Capítulo 7. Trabalhando em equipe com branches remotas
Figura 7.8: Branch master do repositório outro apontando para o novo com-
mit
125
7.5. Obtendo commits de uma branch remota Casa do Código
126
Casa do Código Capítulo 7. Trabalhando em equipe com branches remotas
Na saída, teríamos:
Removing principal.css
Merge made by the ’recursive’ strategy.
index.html | 29 +++++++++++++++++++++--------
js/principal.js | 2 +-
principal.css | 11 -----------
3 files changed, 22 insertions(+), 20 deletions(-)
delete mode 100111 principal.css
127
7.6. Mesclando branches remotas e locais Casa do Código
128
Casa do Código Capítulo 7. Trabalhando em equipe com branches remotas
129
7.6. Mesclando branches remotas e locais Casa do Código
$ git pull
130
Casa do Código Capítulo 7. Trabalhando em equipe com branches remotas
principal.css | 11 -----------
3 files changed, 22 insertions(+), 20 deletions(-)
delete mode 100111 principal.css
131
7.6. Mesclando branches remotas e locais Casa do Código
132
Casa do Código Capítulo 7. Trabalhando em equipe com branches remotas
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title>Entre em contato conosco</title>
</head>
<body>
<h1>Fale com a gente.</h1>
<p>Dúvidas, sugestões ou choramingos</p>
<form>
<label for="nome">Nome</label>
<input id="nome">
<label for="email">Email</label>
<input id="email">
133
7.7. Deletando branches remotas Casa do Código
<label for="mensagem">Mensagem</label>
<textarea id="mensagem"></textarea>
<input type="submit" value="Enviar">
</form>
</body>
</html>
Mas nosso cliente, que é um pouco indeciso, voltou atrás e quis simplificar
o projeto, parando o desenvolvimento da página de contato e deixando apenas
o e-mail na página principal.
Devido a essa mudança nos requisitos, resolvemos remover nossa branch
contato mudando para a branch master do nosso repositório e execu-
tando o comando git branch -D contato.
Mas quando executamos o comando anterior, removemos apenas a
branch local contato. Lá no GitHub, a branch contato continua intacta.
E a nossa branch remota origin/contato, que aponta para a branch cor-
respondente do GitHub, também continua no nosso repositório.
Podemos constatar isso executando novamente o comando git branch
-a -v:
134
Casa do Código Capítulo 7. Trabalhando em equipe com branches remotas
Teríamos na saída:
To git@github.com:fulanodasilva/moveis-ecologicos.git
- [deleted] contato
135
Capítulo 8
Em geral, criamos tags com nomes como v1.0, v1.1, v2.0 e assim
por diante. Cada equipe deve definir o seu padrão.
$ git tag
138
Casa do Código Capítulo 8. Controlando versões do código com tags
v1.0
Imagine que tenhamos errado o nome de uma tag. Por exemplo, criamos
a tag verssao1 com o comando git tag verssao1. Podemos deletá-la
com o comando:
Na saída, teremos:
139
8.3. Compartilhando tags com a sua equipe Casa do Código
commit 0f8d4b3000000000000000000000000000000000
Author: Fulano da Silva <fulanodasilva.git@gmail.com>
Date: Fri Jun 13 17:14:16 2014 -0300
140
Casa do Código Capítulo 8. Controlando versões do código com tags
Pronto! A tag v1.0 foi enviada para o repositório remoto origin. Nos-
sos colegas de equipe poderão obter essa tag quando executarem o comando
git pull.
Mas ainda temos outras tags para compartilhar: as tags banners e v1.1.
Executar o comando git push para cada tag é algo bastante tedioso.
Se quisermos enviar todas as novas tags do repositório local para um
repositório remoto podemos utilizar o comando git push com a opção
--tags:
Na saída, teremos:
141
Capítulo 9
Outra coisa que nosso cliente nos informou é que a página da Móveis
Ecológicos S. A. estava sendo copiada por outras empresas do ramo.
Sugerimos algumas soluções para minimizar o problema mas nosso cli-
ente decidiu por uma maneira simples: colocar um rodapé na página com o
símbolo de copyright. Mas o rodapé teria que ser bonito, “o rodapé mais belo
de todos os tempos”, segundo nosso cliente.
Para podermos trabalhar com calma em busca do rodapé perfeito, pas-
sando a trabalhar na branch design depois de executar o comando git
checkout design.
Depois de algum esforço chegamos a um design utilizando classes do fra-
mework CSS Bootstrap. Modificamos o arquivo index.html conforme a
seguir:
144
Casa do Código Capítulo 9. Lidando com conflitos
Listando o histórico dos últimos dois commits com o comando git log
-n 2 --oneline --decorate --all, teríamos:
Auto-merging index.html
Merge made by the ’recursive’ strategy.
index.html | 3 +++
1 file changed, 3 insertions(+)
145
9.2. Conflitos após um merge com mudanças em um mesmo arquivo Casa do Código
146
Casa do Código Capítulo 9. Lidando com conflitos
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed;fix conflicts and then commit the result.
147
9.2. Conflitos após um merge com mudanças em um mesmo arquivo Casa do Código
Mesmo sendo muito bom para fazer o merge automático, dessa vez o Git
não conseguiu mesclar o arquivo index.html de maneira clara porque fo-
ram feitas alterações na mesma região do arquivo.
De forma cautelosa, o Git marcou um conflito com os caracteres <, = e
>.
Entre os textos <<<<<<< HEAD e ======= estão as alterações que fize-
mos na branch master, que é a branch atual, para qual o HEAD está apon-
tando.
Já entre ======= e >>>>>>> design, estão as alterações que fizemos
na branch design.
Ao executarmos git status, teremos:
On branch master
Your branch is ahead of ’origin/master’ by 5 commits.
(use "git push" to publish your local commits)
Unmerged paths:
(use "git add <file>..." to mark resolution)
Note que o arquivo index.html aparece como não mesclado, como both
modified sob Unmerged paths (nomes não muito intuitivos).
Agora teremos que realizar o merge manualmente. Nesse caso, a solução
é fácil. Vamos editar o arquivo index.html da seguinte maneira:
148
Casa do Código Capítulo 9. Lidando com conflitos
On branch master
Your branch is ahead of ’origin/master’ by 5 commits.
(use "git push" to publish your local commits)
Changes to be committed:
modified: index.html
149
9.3. Resolvendo conflitos após um rebase Casa do Código
150
Casa do Código Capítulo 9. Lidando com conflitos
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Failed to merge in the changes.
Patch failed at 0004 Adicionando texto criativo
The copy of the patch that failed is found in:
/home/fulanodasilva/moveis/.git/rebase-apply/patch
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)
no changes added to commit (use "git add" and/or "git commit -a")
151
9.4. Usando uma ferramenta para resolver conflitos Casa do Código
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: index.html
152
Casa do Código Capítulo 9. Lidando com conflitos
$ git mergetool
Leia com atenção a mensagem anterior. Repare que o Git listou algumas
ferramentas para resolução de conflitos como Meld (http://meldmerge.org) ,
bem simples e efetiva que funciona em Windows, Mac OS e Linux, Tortoi-
seMerge (http://tortoisesvn.net/TortoiseMerge.html) , bastante utilizada mas
só para Windows, entre outras.
Alguma das ferramentas listadas anteriormente será procurada e invo-
cada.
Na mensagem anterior, foi indicada a ferramenta Meld. Pressionando a
tecla Enter, a ferramenta é aberta:
153
9.4. Usando uma ferramenta para resolver conflitos Casa do Código
On branch master
Your branch is ahead of ’origin/master’ by 5 commits.
(use "git push" to publish your local commits)
154
Casa do Código Capítulo 9. Lidando com conflitos
Changes to be committed:
modified: index.html
Untracked files:
(use "git add <file>..." to include in what will be committed)
index.html.orig
155
Capítulo 10
Mas como usar tudo isso que aprendemos no seu projeto? Qual a melhor
maneira trabalhar com o Git no seu caso?
158
Casa do Código Capítulo 10. Maneiras de trabalhar com Git
$ git add .
$ git commit -m "Otimizando consulta a clientes"
159
10.1. Utilizando só a branch master com um repositório central Casa do Código
$ git add .
$ git rebase --continue
Quando utilizar?
Para equipes pequenas ou na adoção do Git.
Quando trabalhamos em equipes pequenas, com até 5 desenvolvedores,
quanto mais simples o fluxo de trabalho, melhor. Como a equipe é pequena,
muito provavelmente o projeto será pequeno e teremos controle no ritmo das
entregas, não precisando de um fluxo mais poderoso (e complexo).
Esse fluxo é parecido com a maneira como são comumente utilizados sis-
temas de controle de versão centralizados, como o Subversion. Por isso, para
160
Casa do Código Capítulo 10. Maneiras de trabalhar com Git
equipes que estão iniciando com o Git, é o fluxo de mais fácil adoção. A equipe
pode focar em aprender os comandos básicos do Git, utilizados para lidar com
um repositório local, para depois partir para fluxos mais avançados.
Vantagens
Desvantagens
161
10.2. Utilizando branches por funcionalidade com um repositório central Casa do Código
Para projetos open source, é algo inviável. Para projetos e equipes muito
grandes, pode também ser um problema.
162
Casa do Código Capítulo 10. Maneiras de trabalhar com Git
online. Antes de começar, vamos criar a partir da master uma branch cha-
mada pedidos, já mudando pra essa nova branch:
$ git add .
$ git commit -m "Tela inicial de pedidos"
163
10.2. Utilizando branches por funcionalidade com um repositório central Casa do Código
$ git add .
$ git rebase --continue
164
Casa do Código Capítulo 10. Maneiras de trabalhar com Git
nesse caso porque, muito provavelmente, será feito um merge do estilo fast-
forward, já que não é comum fazermos commits diretamente na master.
Na branch pedidos, devemos executar os comandos:
$ git add .
$ git commit -m "Resolvendo conflitos no merge de pedidos"
165
10.2. Utilizando branches por funcionalidade com um repositório central Casa do Código
Quando utilizar?
Em projetos um pouco maiores, principalmente se já tiverem algumas
entregas feitas. É importante que a equipe tenha familiaridade no uso do Git.
Para projetos que já estão a todo vapor, com melhorias e correções que
precisam ser feitas de imediato, isolar código que ainda está sendo desenvol-
vimento é algo importante. Com o uso de uma branch para cada funciona-
lidade, podemos organizar o desenvolvimento das novas funcionalidades de
maneira a não afetar demandas urgentes.
Para que essa fluxo seja usado com fluência, é preciso que os desenvolve-
dores já estejam confortáveis com o uso básico do Git.
Vantagens
• Pode ser entregue apenas parte das funcionalidades que estão sendo
desenvolvidas, possibilitando mudanças mais tranquilas na estratégia
de negócio do nosso cliente.
Desvantagens
166
Casa do Código Capítulo 10. Maneiras de trabalhar com Git
167
10.3. Utilizando branches por etapa de desenvolvimento com um repositório central Casa do Código
quenos bugs descobertos logo antes de liberar uma versão. Teriam nomes
como release1.1 ou release2.0 e seriam criadas a partir da desenv.
Também poderiam ser comitados nessas branches de release códigos neces-
sários para preparar uma entrega, como arquivos de versão e release notes.
Seriam branches de curto prazo, que poderiam ser deletadas quando não fize-
rem mais sentido. Os commits das correções feitas nessas branches de release
precisariam ser aplicados na master e na desenv, através de um merge.
Para bugs urgentes, que afetam versões em produção, poderíamos criar
uma branch de hotfix. Se estivermos com a versão 1.0 em produção e aconte-
cer um defeito que pode ser corrigido de maneira imediata, poderíamos criar
a branch hotfix-1.0.1 a partir da master. A correção seria feita nessa
nova branch e, quando finalizada, faríamos um merge na branch master.
Também é importante efetuarmos um merge na branch desenv, para obter-
mos a correção do defeito. Uma branch de hotfix é de curto prazo e, depois
de feito o merge, podemos apagá-la.
168
Casa do Código Capítulo 10. Maneiras de trabalhar com Git
//github.com/empresa/projeto.git .
Logo no início do projeto, ou em algum outro momento apropriado, po-
demos criar uma branch local chamada desenv, a partir da master, para
comitarmos código ainda em desenvolvimento. Também é importante que
essa branch exista no repositório central. Para isso, um dos desenvolvedores
deve executar:
169
10.3. Utilizando branches por etapa de desenvolvimento com um repositório central Casa do Código
170
Casa do Código Capítulo 10. Maneiras de trabalhar com Git
Quando utilizar?
Em projetos complexos, que já têm várias entregas e com diversas novas
funcionalidades em desenvolvimento. A equipe já deve ter um bom domínio
do Git.
Esse fluxo que usa branches por etapa de desenvolvimento deixa o tra-
balho bastante organizado. A branch de desenvolvimento serve como uma
branch de integração para as diferentes branches de funcionalidade. Já a
171
10.3. Utilizando branches por etapa de desenvolvimento com um repositório central Casa do Código
branch master não é afetada pelo dia a dia, ficando bastante estável porque
só tem novo código nos momentos de entrega e correções urgentes. Ajustes
finos e código para preparar a entrega tem seu lugar, nas branches de release.
Bugs urgentes podem ser corrigidos nas branches de hotfix.
Devido à complexidade no uso das variadas branches, para trabalhar
dessa maneira, o domínio dos conceitos do Git pelos membros da equipe é
bastante importante.
Um fluxo parecido com esse é chamado por alguns de Gitflow, mas não
é um fluxo “oficial”, apesar do apelido. Foi descrito por Vincent Driessen em
2010, em seu blog: http://nvie.com/posts/a-successful-git-branching-model/
Vantagens
• A branch master fica bem estável, podendo ser utilizada até para dis-
parar implantações automáticas do software.
172
Casa do Código Capítulo 10. Maneiras de trabalhar com Git
Desvantagens
• Mesmo com a branch desenv, que serve como uma branch de inte-
gração, só integraremos efetivamente o código nos momentos em que
fizermos o merge das branches das funcionalidades na desenv. Por
isso, especialistas em integração contínua ainda criticam o uso desse
fluxo, argumentando que essa integração ainda é feita tarde demais. Se
esse fluxo for utilizado sem branches por funcionalidade, a situação é
melhorada, mas perderíamos as vantagens de isolarmos o código das
funcionalidades em desenvolvimento.
173
10.4. Colaborando com projetos open source com Fork e Pull Request Casa do Código
push para sua cópia do projeto. Se desejar, pode até liberar acesso de push ao
seu repositório remoto para outras pessoas colaborarem na sua cópia.
Quando o colaborador estiver satisfeito com seu código, é possível enviar
um pull request para o projeto principal. O mantenedor do projeto, a pessoa
responsável pelo repositório original, pode revisar a cópia pública do colabo-
rador e sugerir melhorias no código.
Quando o mantenedor estiver satisfeito, é possível aceitar o pull request,
aplicando as mudanças no repositório original.
É interessante que o colaborador faça seus commits em uma branch de
funcionalidade, separada da master. Dessa maneira, na hora de aplicar o
pull request, o mantenedor do projeto original teria os commits do colabora-
dor em uma branch separada, podendo comitar melhorias. Também é possí-
vel utilizar branches por etapa de desenvolvimento para projetos open source
maiores.
Quando utilizar?
Em projetos open source de pequeno ou médio porte.
Para projeto open source muito grandes, com milhares de colaboradores,
o número de pull requests seria tão grande que tornaria inviável o uso desse
fluxo.
174
Casa do Código Capítulo 10. Maneiras de trabalhar com Git
Vantagens
Desvantagens
175
10.5. Organizando projetos open source gigantescos com Ditador e Tenentes Casa do Código
176
Casa do Código Capítulo 10. Maneiras de trabalhar com Git
Quando utilizar?
Para projetos open source grandes, com milhares de colaboradores.
Vantagens
Desvantagens
177
Capítulo 11
Figura 11.1: Página do GitHub for Windows com o botão para download
Versões suportadas
180
Casa do Código Capítulo 11. Apêndice GitHub no Windows
Após a instalação ser concluída veremos uma tela onde devemos informar
nosso usuário e senha cadastrados no GitHub, e clicar no botão Log in:
181
11.1. Instalando o GitHub for Windows Casa do Código
182
Casa do Código Capítulo 11. Apêndice GitHub no Windows
Por fim, veremos a tela onde serão listados os repositórios Git encontra-
dos em nosso computador, se houver, ou uma mensagem informando que não
foram encontrados repositórios. No nosso caso clicaremos no botão Skip,
pois vamos adicionar os repositórios posteriormente.
183
11.1. Instalando o GitHub for Windows Casa do Código
184
Casa do Código Capítulo 11. Apêndice GitHub no Windows
185
11.2. Criando um novo repositório Casa do Código
186
Casa do Código Capítulo 11. Apêndice GitHub no Windows
187
11.3. Efetuando commits no repositório Casa do Código
Repare que a tela agora está dividida em três colunas, onde na primeira
são listados os repositórios Git, na segunda os commits do repositório junta-
mente com um formulário para efetuar um novo commit, e na última coluna
são exibidos os arquivos do repositório.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<title>GitHub for Windows</title>
</head>
<body>
<h1>Bem vindo!</h1>
</body>
188
Casa do Código Capítulo 11. Apêndice GitHub no Windows
</html>
189
11.4. Detalhando os commits Casa do Código
Repare que na listagem dos arquivos é possível selecionar quais dos ar-
quivos serão comitados.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<title>GitHub for Windows</title>
</head>
<body>
<h1>Bem vindo!</h1>
<p>Alteracao qualquer</p>
</body>
</html>
190
Casa do Código Capítulo 11. Apêndice GitHub no Windows
191
11.4. Detalhando os commits Casa do Código
É possível reverter algum dos commits facilmente, bastando para isso cli-
car no commit, e na tela de detalhamento do commit clicar no botão revert:
192
Casa do Código Capítulo 11. Apêndice GitHub no Windows
Ao clicar no botão será exibida uma tela onde podemos preencher uma
descrição detalhada do repositório, e escolher se o repositório deverá ser
193
11.5. Enviando o repositório para o GitHub Casa do Código
privado, caso nosso usuário tenha cadastro em algum dos planos pagos do
GitHub.
Após preencher as informações basta clicar no botão Publish moveis-
windows e nosso repositório será enviado para o GitHub:
Figura 11.17: Tela com detalhes do repositório a ser enviado para o GitHub
194
Casa do Código Capítulo 11. Apêndice GitHub no Windows
195
11.6. Trabalhando com branches Casa do Código
Vamos criar uma nova branch chamada testes, clicando no botão citado
anteriormente, digitando o nome testes no campo de texto da tela, e confir-
mar clicando no botão Create testes:
196
Casa do Código Capítulo 11. Apêndice GitHub no Windows
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8"/>
<title>GitHub for Windows</title>
</head>
<body>
<h1>Bem vindo!</h1>
<p>TESTE!</p>
197
11.6. Trabalhando com branches Casa do Código
198
Casa do Código Capítulo 11. Apêndice GitHub no Windows
199
11.6. Trabalhando com branches Casa do Código
200
Casa do Código Capítulo 11. Apêndice GitHub no Windows
201
Índice Remissivo Casa do Código
Índice Remissivo
202
Casa do Código Índice Remissivo
203