Apostila Git

Universidade Federal do Paran
Alcides
ngela
Daniel
Eduardo
Apostila
Gabriel Git
Jhenifer
Paula
Walmes
No a vontade de vencer que ganha o jogo, e
sim a vontade de se preparar para venc-lo.
Paul Bear Bryant

Sumrio
1 Sistemas de controle de verso 9
2 Instalao e Configurao 11
2.1 Instalao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.3 MacOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Configurando Perfil . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 Usurio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2 Atalhos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.3 Ignorar Arquivos . . . . . . . . . . . . . . . . . . . . . . . 20
3 Repositrios Locais 21
3.1 Instrues do Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Meu Primeiro Repositrio . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Complementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Verses de Arquivos Diferentes . . . . . . . . . . . . . . . . . . . 28
3.5 Trabalhando com Ramos . . . . . . . . . . . . . . . . . . . . . . . 37
3.6 Resolvendo conflitos . . . . . . . . . . . . . . . . . . . . . . . . . 48
4 Projetos Remotos 55
4.1 Repositrio remoto pessoal . . . . . . . . . . . . . . . . . . . . . 55
4.2 Repositrio remoto coletivo . . . . . . . . . . . . . . . . . . . . . 58
4.3 Fluxo de trabalho com repositrio remoto, do clone ao push . . 59
4.3.1 Git clone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.2 Git Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.3 Git Pull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.4 Git fetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4 Listar branches locais/remotos . . . . . . . . . . . . . . . . . . . 60
4.5 Adicionar, renomear, deletar remote . . . . . . . . . . . . . . . . . 61
4.5.1 Adicionando repositrios remotos . . . . . . . . . . . . . . 61
4.5.2 Obtendo informaes de um Remoto . . . . . . . . . . . . 61
4.5.3 Renomeado Remotos . . . . . . . . . . . . . . . . . . . . . . 61
4.5.4 Removendo Remotos . . . . . . . . . . . . . . . . . . . . . . 61
4.5.5 Deletar ramos no servidor . . . . . . . . . . . . . . . . . . 62
4.5.6 Clonar apenas um branch, commit ou tag. . . . . . . . . . 62
4.6 Criando um Repositrio Git . . . . . . . . . . . . . . . . . . . . . 62
4.7 Git no servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.8 Configurao de Conexo SSH com Servidor . . . . . . . . . . . 63
5
6 SUMRIO
5 Servios Web para Projetos Git 67

5.1 Servios Web para Git . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.1 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1.2 GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2 Criar um perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2.1 Habilitar comunio . . . . . . . . . . . . . . . . . . . . . 72
5.2.2 Gerenciar repositrios . . . . . . . . . . . . . . . . . . . . 74
5.3 Fluxo de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.4 Macansmos de colaborao . . . . . . . . . . . . . . . . . . . . . 83
5.4.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.4.2 Fork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.4.3 Merge Request . . . . . . . . . . . . . . . . . . . . . . . . 84
5.5 Integrao contnua . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.5.1 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.5.2 GitLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6 Ferramentas grficas 95
6.1 Interfaces Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.1.1 git-gui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.1.2 gitk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.1.3 Outras Interfaces . . . . . . . . . . . . . . . . . . . . . . . 100
6.2 Interfaces de comparao . . . . . . . . . . . . . . . . . . . . . . 106
7 Trabalhando em equipe 115

7.1 Boas prticas de colaborao . . . . . . . . . . . . . . . . . . . . 115
7.2 Modelos de fluxos de trabalho . . . . . . . . . . . . . . . . . . . 118
7.2.1 Centralized workflow . . . . . . . . . . . . . . . . . . . . 118
7.2.2 Feature branch workflow . . . . . . . . . . . . . . . . . . 119
7.2.3 Gitflow workflow . . . . . . . . . . . . . . . . . . . . . . . 120
7.2.4 Forking workflow . . . . . . . . . . . . . . . . . . . . . . 120
7.3 Fluxo de trabalho PET no GitLab . . . . . . . . . . . . . . . . . . . 121
Apndice 122
A Exemplos de rotinas 123
B Dicionrio de termos 133

B.0.1 Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
B.0.2 SSH Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
B.0.3 Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.0.4 Repositrio . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.0.5 Stagin Area . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.0.6 Remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.0.7 Clone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.0.8 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.0.9 Add . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.0.10 Commit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.0.11 Branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
B.0.12 Checkout . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
B.0.13 Merge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
SUMRIO 7
B.0.14 Rm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
B.0.15 Mv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.0.16 Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.0.17 Fetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.0.18 Pull . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.0.19 HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
B.0.20 Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
B.0.21 Stash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
B.0.22 Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
B.0.23 Rebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
B.0.24 Blame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
B.0.25 Bisect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
8 SUMRIO
Captulo 1
Sistemas de controle de
verso
Inicialmente, podemos dizer que Git um Sistema de Controle de Verso,

que permite ao programador armazenar diversas cpias de verso do seu
trabalho, restaurar verses anteriores, sincronizar entre diversos computadores
de trabalho e trabalhar colaborativamente com outros programadores. S
com essas possibilidades j faz do Git uma ferramenta muito til a quem
programa. Mas o Git muito mais! possvel utilizar o Git atravs do Shell
(linha de comando) ou atravs de diversas interfaces grficas e at mesmo
dentro do Rstudio. Voc pode integrar seu projeto com o Github ou Gitlab e
disponibilizar os arquivos na web. Assim, voc pode acess-los e at editar
seus arquivos via navegador. Pode deixar os arquivos pblicos e disponibilizar
seu cdigo comunidade de programadores. Outras pessoas podem at vir a
colaborar nos seus projetos. Neste conceito, voc pode fazer uso ou colaborar
com projetos de outros programadores! Acompanhar o desenvolvimento de
projetos que sequer foram lanados, fazer sugestes, tirar dvidas e entrar em
contato direto com equipes e desenvolvedores. Isso transforma o Github e
Gitlab numa rede social de programadores!
O Git no o nico sistema de controle de verso. Nem foi o primeiro. Os
primeiros sistemas de controle de verso foram lanados na dcada de 70. H
sistemas abertos e proprietrios. E tambm, sistemas que trabalham somente de
forma local, cliente-servidor ou sistema distribudo. Dentre os sistemas abertos,
os mais conhecidos so o Apache Subversion (SVN), Mercurial, Git, Veracity e
Bazzar. Mas, porque tantos sistemas foram desenvolvidos? Cada sistema foi
desenvolvido buscando resolver os mesmos problemas de diferentes formas. A
comunidade desenvolvedora do kernel (ncleo) do Linux utilizava o BitKeeper,
um software proprietrio que decidiu revogar a licena gratuita. Linus Torvalds,
desenvolvedor do primeiro kernel, estudou os diversos softwares de controle
de verso para ser o substituto do BitKeeper. Mas nenhum software atendia as
necessidades, principalmente na performance de um projeto to grande. Ento,
ele iniciou o desenvolvimento do software que ele chamou de Git e em menos
de dois meses todo o gerenciamento do kernel j estava transferido para o
novo sistema.
9
10 CAPTULO 1. SISTEMAS DE CONTROLE DE VERSO
Ento, utilizar o Git a garantia de um sistema robusto de controle de versio-

namento. Um sistema aberto e muito utilizado por programadores, estatsticos
e cientistas de dados.
Seja voc mais um desenvolvedor a resolver os seus problemas e participar
desta comunidade.
Captulo 2
Instalao e Configurao
Agora, devidamente apresentados ao sistema de versionamento Git vamos

utiliz-lo. Porm, antes de comearmos a entender os comandos Git, necess-
rio sua instalao e configurao. Neste captulo veremos primeiramente como
instalar o programa Git em diferentes sistemas operacionais e posteriormente
como configurar algumas opes para viabilizar e facilitar seu uso.
2.1 Instalao
2.1.1 Windows
Usurios Windows devem visitar Git for Windows1 , clicar em Download e

baixar o arquivo .exe.
Aps o download, execute o arquivo e voc ter a tela conforme figura 2.1:
Como de costume, clique em Next. Para dar continuidade a instalao aceite
a licena do Git.
O diretrio apresentado na figura 2.2 vem como default, porm possvel
alterar a instalao para um diretrio de sua preferncia. Depois de selecionado
o caminho da instalao, clique em Next para prosseguir.
Na tela de componentes (figura 2.3) podemos definir atalhos, integrao ao
menu de contexto do Windows Explorer, associao de arquivos e uso de
font TrueType. O Git Bash o prompt de comandos prprio, que alm dos
comandos Git tambm fornece alguns comandos Unix que podem ser bem teis.
J o Git GUI uma interface grfica para trabalhar com Git. recomendvel a
seleo de ambos os itens.
Depois de selecionado os componentes de sua preferncia, clique em Next
para dar continuidade.
1 https://git-for-windows.github.io/
11
12 CAPTULO 2. INSTALAO E CONFIGURAO
Figura 2.1: Printscreen do passo 1

2.1. INSTALAO 13
No passo 4, representado pela figura 2.4, o instalador nos oferece a oportu-

nidade de mudar o nome da pasta no menu iniciar, recomenda-se deixar o
padro para fcil localizao posteriormente.
Na tela de configurao PATH environment,conforme a figura 2.5, podemos
escolher as formas de integrao do Git com o sistema. A primeira opo nos
permite usar o Git apenas pelo Git Bash ( o prompt de comando do Git),
a segunda opo nos possibilita executar os comandos no Git Bash e no
prompt de comando do Windows (cmd.exe), e a terceira opo a juno das
duas de cima, porm alguns comandos do Windows sero substitudos por
comandos Unix com mesmo nome. Essa ltima opo no recomendada, a
primeira opo a desejvel.
Na figura 2.6, temos a configurao de quebra de linha. Windows e sistemas
Unix (Linux, Mac) possuem formatos diferentes de quebra de linha em arquivos
de texto. Se voc escreve um cdigo com quebras de linha no formato Windows,
outra pessoa pode ter problemas ao abrir o mesmo arquivo em um Linux, e vice-
versa. Este passo, portanto, permite normalizar isso. A primeira opo converte
automaticamente os arquivos para padro Windows quando receber algum
arquivo e converter para padro Unix quando comitar (enviar alteraes) ao
repositrio. A segunda opo, no faz nenhuma converso ao receber arquivos,
mas convertem para padro Unix ao comitar. J a terceira opo, o Git
no far nenhuma converso. Recomenda-se a seleo da opo Checkout
Windows-style, commit Unix-Style line endings.
No passo da figura 2.7, temos a configurao do emulador de terminal para
usar com o Git Bash. A primeira opo utiliza o terminal MSys2 (Shell), que
permite utilizar comandos Unix no Windows. J a segunda opo, utiliza o
terminal padro do Windows. Recomendamos a primeira opo. Feito isso, d
continuidade a instalao.
E por ltimo, a figura 2.8, que configura ajustes de performance. Essa opo
para habilitar o sistema de cache de arquivo.

2.1. INSTALAO 15

Feito isso, Next, Finish e o Git est instalado.
2.1.2 Linux
Em qualquer sistema Linux, pode-se utilizar o gerenciador de pacotes da

respectiva distribuio para instalar o Git. Basta executar o cdigo de instalao
de sua respectiva distribuio.
Debian
Em uma sesso de terminal Linux de distribuies Debian (Ubuntu, Mint),
execute o cdigo abaixo. Adicione o ppa para obter a verso mais recente do
Git.
sudo add-apt-repository ppa:git-core/ppa

sudo apt-get update
Agora, execute o comando abaixo para instalao do Git. Siga as instrues

do prompt de comando, primeiro confirmando a instalao dos pacotes e suas
dependncias, depois confirmando a instalao do pacote git-core.
sudo apt-get install git git-core git-man git-gui git-doc \

ssh openssh-server openssh-client
git --version
Para adicionar ferramentas complementares, execute:
sudo apt-get install gitk meld
Arch
2.2. CONFIGURANDO PERFIL 17
pacman -S git openssh meld

git --version
Fedora
yum install git

git --version
Usurios de outra verso do Linux podem visitar Download for Linux2 .
2.1.3 MacOS
Existem duas maneiras de instalar o Git no Mac, uma pelo instalador e outra
atravs do MacPorts.
Utiizando o Instalador
O usurio dever acessar Download for Mac3 , clicar em Download e baixar
o arquivo .dmg.
Aps o download, necessrio clicar duas vezes para ter acesso ao pacote de
instalao. Dentro do arquivo .dmg, execute o arquivo .pkg para iniciar a
instalao. Siga os passos at concluir a instalao. recomendvel utilizar a
instalao padro.
Para testar a instalao, abra o terminal e digite o comando git. A sada
dever ser similar a figura 2.9:
Utiizando o MacPorts
A maneira mais fcil de instalar Git no Mac via MacPorts4 , para isso basta
executar o seguinte comando:
sudo port install git-core
2.2 Configurando Perfil
As configuraes vo determinar algumas opes globais do Git, sendo neces-

srio faz-las apenas uma vez.
2.2.1 Usurio
Os comandos abaixo vo configurar o nome de usurio e endereo de e-mail.

Esta informao importante pois anexada aos commits que voc realiza,
2 https://git-scm.com/download/linux
3 http://git-scm.com/downloads
4 http://www.macports.org
ou seja, as configuraes ficaro associadas ao trabalho em desenvolvimento,

permitindo que os colaboradores/gestores do projeto identifiquem suas contri-
buies. Caso o projeto seja individual, a importncia de configurar usurio
e e-mail se mantm. Uma vez que se trabalha com duas ou mais mquinas,
a maneira de identificar a pessoa que est desenvolvendo o trabalho pelo
nome de usurio.
Em um terminal Bash, execute o cdigo abaixo:
git config --global user.name "Knight Rider"

git config --global user.email "batman@justiceleague.org"
A opo --global usar essa informao para todo projeto Git da mquina.
possvel fazer definies para cada projeto, ou seja, no globais. Para isso
necessrio executar o comando a seguir sem a opo --global.
git config user.name "Knight Rider"

git config user.email "batman@justiceleague.org"
Uma vez configurado o perfil, o Git est pronto para uso.
2.2.2 Atalhos
Os atalhos no Git so chamados de Alias. Com ele podemos mapear comandos

que repetidamente usamos para algumas poucas teclas. Estes atalhos podem
ser criados de dois modos: atravs do comando no terminal ou editando
diretamente no arquivo /.gitconfig.
2.2. CONFIGURANDO PERFIL 19
Pelo terminal:
Execute o comando abaixo com o atalho de sua preferncia e o nome completo
do comando o qual deseja criar o alias.
git config --global alias.nome_do_alias "comando inteiro"
Um exemplo bem simples o seguinte:
git config --global alias.st "status"
Assim, ao executar git st o mesmo que executar git status.

Pelo mtodo citado acima, o alias adicionado automaticamente no seu arquivo
/.gitconfig.
Pelo arquivo /.gitconfig:

Pode-se criar atalhos atravs de um bloco no seu arquivo de configurao. Para
isso, necessrio localizar o diretrio do Git e adicionar a lista de comandos
desejada, como no exemplo:
[alias]
st = status
ci = commit
br = branch
co = checkout
df = diff
Assim que adicionar este bloco com os comandos de sua escolha, ele ir
funcionar imediatamente.
Segue abaixo os caminhos para encontrar o arquivo /.gitconfig nos sistemas
operacionais:
Windows:
1. C:\\Pasta_do_seu_projeto\\.git\\config
2. C:\\Documents and Settings\\Seu_usuario\\.gitconfig
3. C:\\Arquivos de programas\\Git\\etc\\gitconfig
Mac:
1. /Pasta_do_seu_projeto/.git/config
2. /Users/Seu_usuario/.gitconfig
3. /usr/local/git/etc/gitconfig
Linux:
1. Crie um arquivo como sudo dentro da pasta etc/ com nome de
gitconfig e coloque os atalhos de sua escolha.
Obs: Os arquivos de configurao do Git no tem extenso.

No importa o mtodo voc utilize, suas configuraes sempre ficaro salvas
no arquivo /.gitconfig.
2.2.3 Ignorar Arquivos
Usando o arquivo .gitignore podemos ignorar arquivos que no desejamos

versionar no repositrio, pode ser feito por projeto e por usurio. Configurar
um arquivo .gitignore antes de comear a trabalhar, importante, pois evita
commits acidentais de arquivos que no deveriam ir para o seu repositrio Git.
Ignorar Arquivos por Projeto:
Em todos os projetos que necessitam de um controle de verso h sempre
casos em que arquivos no precisam ser versionados. Para isso preciso
criar um arquivo .gitignore no diretrio raiz do projeto, o qual contm
padres (pattern) que sero ignorados, cada padro fica em uma linha como
no exemplo:
$ cat .gitignore
*.[oa]
*~
A primeira linha fala para o Git ignorar qualquer arquivo finalizado em .o

ou .a e a segunda linha ignora todos os arquivos que terminam com um til
(~). Esses padres podem serem feitos de acordo com a necessidade de cada
projeto.
Ignorar Arquivos por Usurio (Globalmente):
Para no precisar criar uma lista de comandos para serem ignorados em cada
projeto, possvel ignorar arquivos em todos os repositrios. Para isso, basta
criar um arquivo .gitignore em seu diretrio home contendo os padres os
quais deseja ignorar e executar o comando abaixo no terminal a partir da pasta
onde est localizado o arquivo .gitignore:
git config --global core.excludesfile ~/.gitignore
A partir disso, todos os arquivos que esto na lista sero ignorados pelo
usurio.
Finalmente com a instalao, configurao essencial (usurio e e-mail) e configu-
raes adicionais concludas, podemos comear a utilizar o Git para versionar
nossos projetos.
Captulo 3
Repositrios Locais
3.1 Instrues do Git
Neste captulo, as instrues sero todas feitas no terminal mesmo que existam
alternativas grficas para as mesmas. Isso enfatiza no que est sendo feito alm
do fato de que no terminal todos devem ter os mesmos recursos e os comandos
iro produzir os mesmos resultados, o que faz esse tutorial algo reproduzvel.
Casos voc queira usufruir das ferramentas grficas v para o captulo 6.
Sabendo que voc executou os comandos de perfil que no captulo anterior,
temos o Git devidamente configurado, com credenciais (nome e e-mail) e
configuraes aplicadas. Vamos ento ver como o sistema de controle de
verso acontece.
## Apenas verificando o cadastro.

git config user.name "Knight Rider"
git config user.email "batman@justiceleague.org"
Todas as instrues do Git so sinalizadas por comear com git seguido da ins-
truo/comando e seus argumentos complementares, se existirem/necessrios.
## Padro de instrues Git.

# git <instruo> <complementos...>
cd meu1repo ## Diretrio de teste de comandos
## Padro de instrues Git.

git <instruo> <complementos ...>
Os comandos abaixo revelam tudo o Git possui, embora dizer o que ele tem
no signifique nada diante do que ele pode fazer com o que tem.
21
22 CAPTULO 3. REPOSITRIOS LOCAIS
## Ajuda resumida do Git, principais comandos com descrio.

git help -a
usage: git [--version] [--help] [-C <path>] [-c name=value]

[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p | --paginate | --no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
<command> [<args>]
available git commands in '/usr/lib/git-core'
add merge-octopus
add--interactive merge-one-file
am merge-ours
annotate merge-recursive
apply merge-resolve
archive merge-subtree
bisect merge-tree
bisect--helper mergetool
blame mktag
branch mktree
bundle mv
cat-file name-rev
check-attr notes
check-ignore pack-objects
check-mailmap pack-redundant
check-ref-format pack-refs
checkout patch-id
checkout-index prune
cherry prune-packed
cherry-pick pull
citool push
clean quiltimport
clone read-tree
column rebase
commit receive-pack
commit-tree reflog
config relink
count-objects remote
credential remote-ext
credential-cache remote-fd
credential-cache--daemon remote-ftp
credential-store remote-ftps
daemon remote-http
describe remote-https
diff remote-testsvn
diff-files repack
diff-index replace
diff-tree request-pull
3.1. INSTRUES DO GIT 23
difftool rerere
difftool--helper reset
fast-export rev-list
fast-import rev-parse
fetch revert
fetch-pack rm
filter-branch send-pack
fmt-merge-msg sh-i18n--envsubst
for-each-ref shell
format-patch shortlog
fsck show
fsck-objects show-branch
gc show-index
get-tar-commit-id show-ref
grep stage
gui stash
gui--askpass status
hash-object stripspace
help submodule
http-backend subtree
http-fetch symbolic-ref
http-push tag
imap-send unpack-file
index-pack unpack-objects
init update-index
init-db update-ref
instaweb update-server-info
interpret-trailers upload-archive
log upload-pack
ls-files var
ls-remote verify-commit
ls-tree verify-pack
mailinfo verify-tag
mailsplit web--browse
merge whatchanged
merge-base worktree
merge-file write-tree
merge-index
git commands available from elsewhere on your $PATH
cola dag
'git help -a' and 'git help -g' list available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
3.2 Meu Primeiro Repositrio
git init
Initialized empty Git repository in /home/walmes/GitLab/apostila-git/meu1repo/.git/
O Git retorna a mensagem de inicializao do repositrio. Nesse momento

ele cria um diretrio oculto .git/ com subdiretrios que so o corao do
sistema de versionamento. Voc no deve modificar nada nesse diretrio.
por essa razo que ele oculto. Alterar o contedo pode prejudicar ou
interromper o funcionamento do Git. Se voc quiser encerrar o processo
de versionamento fazendo com que esse diretrio seja como qualquer outro
diretrio, s excluir a diretrio .git/. Cada subdiretrio do .git/ tem um
propsito mas deixaremos os esclarecimentos para o futuro. Por agora vamos
apenas conferir a sua estrutura.
## Mostra todo contedo do diretrio.

tree --charset=ascii -a
.
`-- .git
|-- branches
|-- config
|-- description
|-- HEAD
|-- hooks
| |-- applypatch-msg.sample
| |-- commit-msg.sample
| |-- post-update.sample
| |-- pre-applypatch.sample
| |-- pre-commit.sample
| |-- prepare-commit-msg.sample
| |-- pre-push.sample
| |-- pre-rebase.sample
| `-- update.sample
|-- info
| `-- exclude
|-- objects
| |-- info
| `-- pack
`-- refs
|-- heads
`-- tags
10 directories, 13 files
NOTA: o tree um programa instalado a parte (third party software) que re-
torna arte ASCII representado a estrutura de diretrios. Se voc usa distribuio
Debian, instale com sudo apt-get install tree. Windows: tree.
3.2. MEU PRIMEIRO REPOSITRIO 25
Vamos comear da maneira mais simples: criando um arquivo com uma linha
de texto apenas. Bem, vale avisar que ao longo desse captulo, os arquivos
sero sempre bem pequenos e dificilmente realistas, mas como o enfoque est
no funcionamento, no haver prejuzo.
Vamos criar o arquivo com contedo tambm pelo terminal. Se voc preferir,
abra eu editor de texto favorito (Emacs, Gedit, Geany, RStudio, Bloco de Notas,
Notepad++, etc) e faa algo mais criativo.
## Cria um arquivo com uma linha de contedo.

echo "Meu primeiro repositrio Git" > README.txt
## Lista os arquivos do diretrio.

## tree --charset=ascii
## Reconhecimento do Git sobre aquivo criado.

git status
On branch master
Initial commit
Untracked files:
(use "git add <file>..." to include in what will be committed)
README.txt
nothing added to commit but untracked files present (use "git add" to track)
E o que o Git acha de tudo isso? O comando status o mais usado do Git,
principalmente nas etapas de aprendizado. Uma caracterstica diferente do Git,
se comparado a outras aplicaes de uso por terminal, que ele realmente
camarada. Nas mensagens de output, o Git informa o que aconteceu e tambm
sugere o que fazer.
Este diretrio agora um diretrio sob versionamento Git, portanto todas as
alteraes realizadas sero observadas pelo sistema. Ao criarmos o arquivo e
pedirmos a situao (status), o Git indica que existe um arquivo no rastreado
(untracked) no diretrio. Inclusive sugere uma ao que seria adicionar o aquivo
(add). Se o seu sistema operacional est em portugus, parte dos outputs do
Git podem estar traduzidos.
De forma geral temos 3 estgios 3.1 de arquivos considerados no sistema
de controle de versionamento Git. So eles working directory, Staged Area e
Committed, os discutiremos ao logo do texto. Todo arquivo criado em um
diretrio versionado deve necessariamente passar pelos trs estgios. Voltando
para a nossa situao temos o arquivo README.txt criado e atualmente ele est
no estgio working directory, faremos todo o procedimento para que chegue ao
estgio committed.
Alteraes em arquivos no working directory no so armazenadas, por isso
o sugestivo nome diretrio de trabalho. Portanto, para que o arquivo seja
Figura 3.1: Passos para versionamento
includo no monitoramento necessrio que ele receba o primeiro comando

add. Isso marca a entrada dele no projeto como um arquivo que a partir de
ento ser versionado.
Para que o arquivo seja includo no monitoramento necessrio que ele receba
o primeiro comando add. Isso marca a entrada dele no projeto como um
arquivo que a partir de ento ser versionado. O status agora no indica mais
que ele est untracked mas sim que existem mudanas para serem registradas
(changes to be commited). A melhor traduo de commit, pensando no seu uso
em Git, fechar sob segurana. Quando um commit feito, cria-se um instante
na linha do tempo que salva o estado do projeto. Para esse instante o projeto
pode ser retrocedido, voltando o condio/contedo de todos os arquivos para
o momento no qual o mencionado commit foi feito. Voc pode voltar para um
commit de semanas e at anos atrs.
O controle de verso no apenas voltar os arquivos para o contedo que eles
tinham no passado. Arquivos rastreados que foram deletados ou renomeados
so recuperados. At mesmo as permisses de leitura/escrita/execuo dos
arquivos so contempladas no versionamento.
## O primeiro àdd` submete o arquivo ao versionamento.

git add README.txt
git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached <file>..." to unstage)
new file: README.txt

3.3. COMPLEMENTOS 27
O arquivo README.txt j visto pelo Git como um arquivo com o qual ele
deve se preocupar, pois est sob versionamento. Vamos agora fazer um
registro definitivo sobre o estado desse arquivo (commit). de fundamental
importncia que a mensagem de notificao, ou mensagem de commit, reflita
as modificaes feitas. So as mensagens que sero consultadas quando voc
precisar desfazer/voltar. Ela deve ser curta (<= 72 caracteres) e ao mesmo
tempo informativa. A minha primeira mensagem no ser, todavia.
Boas Prticas de commit:
Verbo no indicativo
Frases curtas
Dizer o que fez e no como fez
Evite mensagens de commit como:
"Modificaes realizadas"
"Trabalhei muito hoje"
"Terminando este trabalho na madruga"
## Registro de verso.
git commit -m 'Cria arquivo com ttulo'
[master (root-commit) 612c338] Cria arquivo com ttulo

1 file changed, 1 insertion(+)
create mode 100644 README.txt
O retorno da instruo de commit indica o nmero de arquivos includos no

commit e o nmero de inseres e delees de linhas. O mais importante est
na primeira linha que informa o ramo de trabalho atual (branch) e o sha1 do
commit. O sha1 uma sequncia hexadecimal de 40 dgitos que representa
unicamente o commit, ento so 1640 possibilidades. por meio do sha1 que
podemos retroceder o projeto. So mostrados apenas os 7 primeiros dgitos
porque so suficientes para diferenciar commits, seja de projetos pequenos ou
at mesmo de projetos moderados ou grandes.
3.3 Complementos
Para o registro de desenvolvimento, existe marcao por tags, que seriam

commits especiais, geralmente usado para marcar pontos de destaque do
projeto, por exemplo verso alfa, beta, teste servidor.
# Criando a tag
git tag versao2
# Podemos marcar uma tag com um commit

git tag -a versao2 -m "Verso 2 est pronta"
# Para ver todas as tags

git tag
# Excluir tags
git tag -d versao1
Caso haja mudana no nome do arquivo que voc esteja versionado, deve ser
alterado pelo prprio Git, para que fique no atual estgio de versionamento.
## git mv antigo novo

git mv -f README.txt LEIAME.txt
Caso voc queira excluir o arquivo
git rm README.txt
3.4 Verses de Arquivos Diferentes

Vamos criar mais arquivos e acrescentar contedo ao j rastreado pelo Git para
percebermos o funcionamento. Escrever uma lista de razes para usar o Linux.
Deixei a lista curta poder ampliar no futuro e com erros de portugus para
corrigir depois.
## Adiciona mais linhas ao README.txt

echo "
A filosofia do Linux 'Ria na face do perigo'.
pa. Errado. 'Faa voc mesmo'. , essa.
-- Lunus Torvalds" >> README.txt
## Cria uma lista de pontos sobre o porqu de usar o Linux.

echo "Por que usar o Linux?
* livre
* seguro
* customizavel" > porqueLinux.txt
## Mostra o contedo do arquivo.

less README.txt
Meu primeiro repositrio Git

3.4. VERSES DE ARQUIVOS DIFERENTES 29
A filosofia do Linux 'Ria na face do perigo'.

pa. Errado. 'Faa voc mesmo'. , essa.
-- Lunus Torvalds

less porqueLinux.txt
Por que usar o Linux?
* livre
* seguro
* customizavel
git status
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: README.txt
Untracked files:
porqueLinux.txt
no changes added to commit (use "git add" and/or "git commit -a")
O Git retornou dois campos. No primeiro ele diz que existem mudanas no
README.txt no encaminhadas para receber registro (not staged for commit) e
no segundo ele aponta que o porqueLinux.txt um arquivo no rastreado
(fora de monitoramento).
Vamos explorar um pouco mais os recursos do Git antes de adicionar as
recentes mudanas. At o momento, temos apenas um commit feito. Para
acessar o histrico de registros usamos git log. O histrico mostra o sha1, o
autor, data e mensagem de commit. Uma sada mais enxuta obtida com git
log --oneline, til quando o histrico longo. possvel fazer restrio no
git log, como mostrar os commits a partir de certa data, certo intervalo de
datas, para um nico autor ou nico arquivo.
## Mostra o histrico de commits.

git log
commit 612c338a6480db837dcef86df149e06c90ed6ded
Author: Walmes Zeviani <walmes@ufpr.br>
Date: Thu Dec 17 09:29:02 2015 -0200
Cria arquivo com ttulo
O comando diff mostra as diferenas no contedo dos arquivos/diretrio. No

caso, apenas o README.txt est sendo rastreado, por isso o output indica a
adio (+) de novas linhas. Na sada tem-se os sha1 das verses comparadas e
o intervalo de linhas envolvido na poro modificada (@@). Visite: git-diffs.
## Diferena nos arquivos versionados.

git diff
diff --git a/README.txt b/README.txt

index 07d3585..d0af1d3 100644
--- a/README.txt
+++ b/README.txt
@@ -1 +1,5 @@
+
+A filosofia do Linux 'Ria na face do perigo'.
+pa. Errado. 'Faa voc mesmo'. , essa.
+ -- Lunus Torvalds
Vamos aplicar o primeiro add ao porqueLinux.txt para que ele comece a ser
versionado. Perceba que ao adicion-lo, as mudanas, no caso a criao do
arquivo com contedo, j so separadas para receber registro (changes to be
commited).
## Adiciona o arquivo ao processo de reastreamento.

git add porqueLinux.txt
git status
On branch master
(use "git reset HEAD <file>..." to unstage)
new file: porqueLinux.txt

## Mensagem que registra as modificaes adicionadas.

git commit -m "Lista de inicial de o porqu usar o Linux."
[master 8acac99] Lista de inicial de o porqu usar o Linux.

1 file changed, 5 insertions(+)
create mode 100644 porqueLinux.txt
git status
On branch master
Ainda resta o REAMDE.txt para receber registro. Voc no precisa fazer agora.
Pode continuar editando caso no tenha atingido uma quantidade de modi-
ficao merecedora de commit. Lembre-se que registros geram contedo no
diretrio .git. Quanto mais commits, mais contedo gerado. Mas tambm,
toda vez que voc faz um commit, voc define um ponto de retorno, um estado
salvo, caso precise no futuro recuperar/visitar. O que uma unidade de
modificao comitvel voc ir definir aos poucos com a prtica.
## Encaminha o arquivo para receber registro.

git add README.txt
git status
On branch master
(use "git reset HEAD <file>..." to unstage)
## Atribui mensagem de notificao.

git commit -m "Adiciona frase do Linux Torvalds."
[master 1aa33c3] Adiciona frase do Linux Torvalds.

Agora temos 3 commits e o log apresenta os sha1 e as mensagens corresponden-

tes aos mesmos. Com --oneline resumimos o output mostrando apenas o sha1
e a mensagem de commit.
git log --oneline
1aa33c3 Adiciona frase do Linux Torvalds.

8acac99 Lista de inicial de o porqu usar o Linux.
612c338 Cria arquivo com ttulo
Por meio dos sha1, podemos aplicar o diff para visitarmos as modificaes
entre dois commits, no necessariamente consecutivos, por exemplo. Tambm
podemos retroceder (checkout, reset, revert) o projeto para alguns desses pontos.
git diff HEAD@{1}

index 07d3585..d0af1d3 100644
--- a/README.txt
+++ b/README.txt
@@ -1 +1,5 @@
+
+ -- Lunus Torvalds
Instrumos o Git mostrar as diferenas para um commit atrs. A cabea (HEAD)

o que se entende como estado mais recente. Usa-se o termo HEAD (cabea)
pois considera-se um crescimento do histrico debaixo para cima no qual um
novo commit colocado em cima dos demais (empilhado). O HEAD@{0} ou
apenas HEAD representa o ltimo registro feito. No necessrio escrever o
ltimo HEAD na instruo abaixo.
Agora inspecionado uma distncia de 2 commits a partir do ltimo. Aqui tem-se
os dois arquivos envolvidos nesse intervalo de 2 commits. Com --name-only
retorna-se s o nome dos arquivos.
git diff HEAD@{2} HEAD@{0}

index 07d3585..d0af1d3 100644
--- a/README.txt
+++ b/README.txt
@@ -1 +1,5 @@
+
+ -- Lunus Torvalds
diff --git a/porqueLinux.txt b/porqueLinux.txt
new file mode 100644
index 0000000..8ecdfda
--- /dev/null
+++ b/porqueLinux.txt
@@ -0,0 +1,5 @@
+Por que usar o Linux?
+
+* livre
+* seguro
+* customizavel
git diff --name-only HEAD@{2} HEAD@{0}
README.txt
porqueLinux.txt
Vamos resolver logo o caso da palavra sem acento em porqueLinux.txt. Voc

abre o arquivo no seu editor de texto e modifica conforme necessrio. A
modificao compreende um linha apenas mas a lembrei de mais coisas e
acrescentei. O git diff mostra as diferenas. Epa! As diferenas no eram
entre commits? O contedo adicionado ainda no recebeu notificao!
## Depois de corrigir palavras e adicionar contedo.

git status
On branch master
modified: porqueLinux.txt
O Git sugere voc aplicar add para preparar para commit. Caso as modificaes
sejam um engano e no mais desejadas, voc pode desfaz-las, abandonar a
correo/incluso das palavras usando checkout. Vamos aplic-lo para ver
como funciona.
## Palavras corrigidas e mais itens adicionados.

* livre
* seguro
* customizvel
* Tem repositrios de software
* Atualizao constante
* Desempenho
## Abandona modificaes feitas presentes no arquivo.

git checkout -- porqueLinux.txt
* livre
* seguro
* customizavel
Bateu o arrependimento? Tem formas de poder retroceder com mudanas ainda

no registradas mas mantendo a possibilidade de recuper-las. Mostraremos
em breve.
NOTA: sempre que quiser testar um comando novo e no est seguro do que
ele faz ou da extenso dos seus efeitos, faa uma cpia do projeto em outro
diretrio e experimente ele l. Isso previne sabores amargos, pois algumas
aes podem ser irreversveis.
## Depois de desfazer as modificaes no porqueLinux.txt

git status
On branch master
nothing to commit, working directory clean
Vamos seguir com as modificaes em porqueLinux.txt que corrigem o texto

e acrescentam itens novos.
git status
On branch master
O diff vazio compara o diretrio de trabalho com o ltimo registro (ltimo

commit). Quando voc usa explicitamente na instruo HEAD@{ } seguido
de nmero, ento esto sendo comparadas verses commitadas. Existem
variantes de sufixo para usar no HEAD que so:
HEAD@{n}
HEADn
HEAD~n
em que n um nmero inteiro no negativo. Cada sufixo tem uma finalidade

que no detalharemos agora. Visite: git-caret-and-tilde.
## Modificaes no diretrio vs ltimo commit.

git diff

index 8ecdfda..8747d1e 100644
--- a/porqueLinux.txt
@@ -2,4 +2,7 @@ Por que usar o Linux?
* livre
* seguro
-* customizavel
+* customizvel
+* Tem repositrios de software
+* Atualizao constante
+* Desempenho
## ltimo commit vs dois ancestrais, usando ~.

git diff HEAD~1 HEAD~0

index 07d3585..d0af1d3 100644
--- a/README.txt
+++ b/README.txt
@@ -1 +1,5 @@
+
+ -- Lunus Torvalds
## ltimo commit vs seu ancestral, usando @{}.


index 07d3585..d0af1d3 100644
--- a/README.txt
+++ b/README.txt
@@ -1 +1,5 @@
+
+ -- Lunus Torvalds
## ltimo commit vs dois ancestrais.

## git diff HEAD~2 HEAD~0

index 07d3585..d0af1d3 100644
--- a/README.txt
+++ b/README.txt
@@ -1 +1,5 @@
+
+ -- Lunus Torvalds
index 0000000..8ecdfda
--- /dev/null
@@ -0,0 +1,5 @@
+Por que usar o Linux?
+
+* livre
+* seguro
+* customizavel
Para ficar claro daqui em diante, voc pode ao invs de pedir log, pedir o
reflog que inclu as referncias em termos da sequncia do mais recente para
os seus ancestrais.
## Mostra referncias para commits os ancentrais.

git reflog
1aa33c3 HEAD@{0}: commit: Adiciona frase do Linux Torvalds.

8acac99 HEAD@{1}: commit: Lista de inicial de o porqu usar o Linux.
612c338 HEAD@{2}: commit (initial): Cria arquivo com ttulo
## Adiciona e commita.
git add porqueLinux.txt
git commit -m "Novos argumentos."
[master 095046c] Novos argumentos.

1 file changed, 4 insertions(+), 1 deletion(-)
O Git permite um nvel de rastreabilidade bem fino. Veja por exemplo que
possvel saber quem modificou e quando cada linha do arquivo e qual o
correspondente sha1 do commit.
3.5. TRABALHANDO COM RAMOS 37
Figura 3.2: Exemplo de esquema de ramificao de um projeto Git
## Mostra quem, onde e o que fez em cada arquivo.

git blame README.txt
^612c338 (Walmes Zeviani 2015-12-17 09:29:02 -0200 1) Meu primeiro repositrio Git
1aa33c31 (Walmes Zeviani 2015-12-17 09:29:02 -0200 2)
1aa33c31 (Walmes Zeviani 2015-12-17 09:29:02 -0200 3) A filosofia do Linux 'Ria na face do perig
1aa33c31 (Walmes Zeviani 2015-12-17 09:29:02 -0200 4) pa. Errado. 'Faa voc mesmo'. , essa.
1aa33c31 (Walmes Zeviani 2015-12-17 09:29:02 -0200 5) -- Lunus Torvald
3.5 Trabalhando com Ramos
Existem vrias formas de se trabalham com ramos veja a figura 3.2. Geralmente
os ramos so feitos sob demandas para adicionar uma caracterstica ao projeto
(feature) ou corrigir um bug. Alguns ramos, por outro lado, so ramos fixos
destinados a receber o desenvolvimento dos ramos de demanda. Esses ramos
so geralmente chamados de devel (development) e release. O ramo master o
default e em geral, para projetos grandes, o master s recebe verses funcionais
do projeito, livre de bugs.
Para criar um ramo, usamos git branch seguido do nome que se deseja.
Vamos criar um ramo para adicionar mais arquivos ou modificaes ao projeto.
## Lista ramos (all), locais e remotos.

## git branch ## S ramos locais
## git branch -r ## S ramos remotos
git branch -a ## Todos os ramos.
* master
## Cria um ramo para adio de contedo, novo segmento.

git branch feature01
## Novo ramo criado aparece.

git branch
feature01
* master
## Muda o HEAD de ramo.

git checkout feature01
Switched to branch 'feature01'
## Situao no novo ramo.

git status
On branch feature01
## Histrico de commits.
git log --oneline
095046c Novos argumentos.

Veja que o novo ramo no comea no zero ou vazio (sem arquivos) e sim a partir
do ramo que seu ancestral, ou seja, ele comea a partir do ltimo commit
existente, por padro. Vamos adicionar um arquivo e commitar. O comando
wget permite baixar arquivos pelo terminal. Ser baixado um arquivo com
um funo para calcular o fator de inflao de varincia (vif, variance inflation
factor) usado em modelos de regresso, disponvel na pgina da Professora
Suely Giolo1 .
## Baixando arquivo da internet. Uma funo do R.

wget 'http://people.ufpr.br/~giolo/CE071/Exemplos/vif.R'
--2015-12-17 09:29:03-- http://people.ufpr.br/~giolo/CE071/Exemplos/vif.R

Resolving people.ufpr.br (people.ufpr.br)... ???.??.???.??, 2801:82:8020:0:8377:0:100:20
Connecting to people.ufpr.br (people.ufpr.br)|???.??.???.??|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 560
Saving to: vif.R
0K 100% 44,0M=0s
2015-12-17 09:29:03 (44,0 MB/s) - vif.R saved [560/560]

1 http://people.ufpr.br/~giolo/CE071/Exemplos/vif.R
## Situao do repositrio aps o download.

git status
On branch feature01
Untracked files:
vif.R
git add vif.R

git commit -m "Adiciona funo R para VIF."
[feature01 826f940] Adiciona funo R para VIF.

create mode 100644 vif.R
## Estrutura do diretrio.
tree --charset=ascii
.
|-- porqueLinux.txt
|-- README.txt
`-- vif.R
## Histrico de commits.
git reflog
826f940 HEAD@{0}: commit: Adiciona funo R para VIF.

095046c HEAD@{1}: checkout: moving from master to feature01
095046c HEAD@{2}: commit: Novos argumentos.
git status
On branch feature01
Ento acabamos de acrescentar um novo aquivo ao projeto. Agora que as

modificaes foram salvas (commit feito) podemos trocar de ramo. Voc vai
ver que ao voltarmos para o ramo master o arquivo baixado da internet vai
desaparecer.
## Volta para o ramo master.

git checkout master
Switched to branch 'master'
## Estrutura do diretrio.
.
|-- porqueLinux.txt
`-- README.txt
O arquivo vif.R no sumiu. Ele est no ramo feature01 e s passar para

o ramo master quando mesclarmos o que existe no feature01 ao master.
Ento assim: mudou de ramo, muda o contedo do diretrio. Fazer isso
bem simples, basta dar um git merge. Antes vamos aprender como saber as
diferenas que existem entre ramos.
## Mostra todas as modificaes, cada linha modificada de cada arquivo.

git diff master feature01
diff --git a/vif.R b/vif.R

index 0000000..a114969
--- /dev/null
+++ b/vif.R
@@ -0,0 +1,20 @@
+vif<-function (obj, digits = 5) {
+ Qr <- obj$qr
+ if (is.null(obj$terms) || is.null(Qr))
+ stop("invalid 'lm' object: no terms or qr component")
+ tt <- terms(obj)
+ hasintercept <- attr(tt, "intercept") > 0
+ p <- Qr$rank
+ if (hasintercept)
+ p1 <- 2:p
+ else p1 <- 1:p
+ R <- Qr$qr[p1, p1, drop = FALSE]
+ if (length(p1) > 1)
+ R[row(R) > col(R)] <- 0
+ Rinv <- qr.solve(R)
+ vv <- apply(Rinv, 1, function(x) sum(x^2))
+ ss <- apply(R, 2, function(x) sum(x^2))
+ vif <- ss * vv
+ signif(vif, digits)
+ }
+
## Mostra s os arquivos modificados.

git diff --name-only master feature01
vif.R
Como voc j havia antecipado, a nica diferena entre os ramos master e

feature01 o arquivo vif.R. Agora s pedir o git merge.
## Mesclando as modificaes em feature01 no master.

git merge feature01 master
Updating 095046c..826f940
Fast-forward
vif.R | 20 ++++++++++++++++++++
create mode 100644 vif.R
git log --oneline
826f940 Adiciona funo R para VIF.

possvel criar um ramo a partir de um commit ancestral ao atual. Isso

extremamente til para resolver os bugs. Vamos fazer um segundo ramo a
partir do commit anterior a incluso do arquivo R.
## Referencias aos commits.

git reflog
826f940 HEAD@{0}: merge feature01: Fast-forward

095046c HEAD@{1}: checkout: moving from feature01 to master
## Volta para antes do arquivo de baixar o vif.R.

git checkout HEAD@{4}
Note: checking out 'HEAD@{4}'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at 095046c... Novos argumentos.
## Qual a situao.
git status
HEAD detached at 095046c

## O histrio existente nesse ponto.

git log --name-only --oneline

porqueLinux.txt
README.txt
porqueLinux.txt
README.txt
J que o commit mais recente dessa histria aponta para o arquivo compras,
vamos checar o seu contedo apenas por medida de segurana.

* livre
* seguro
* customizvel
* Tem repositrios de software
* Atualizao constante
* Desempenho
Dito e feito! Voltamos no tempo para o instante logo aps o commit que
inclu novos itens na lista. Podemos voltar para o presente se estivermos
satisfeitos com o passeio mas tambm podemos criar um ramo aqui, caso isso
seja necessrio. Primeiro vamos voltar para o presente depois mostramos como
criar o ramo.
## Mostra onde estamos.

git branch
* (HEAD detached at 095046c)

feature01
master
Se no fizemos nenhuma modificao, voltar bem simples. Se modificaes

foram feitas necessrio saber se precisam ser mantidas e onde ou se devem
ser descartadas.
## Volta para o presente.

git checkout master
Previous HEAD position was 095046c... Novos argumentos.

git status
On branch master
git log --oneline
826f940 Adiciona funo R para VIF.

## Fenda no tempo fechada. Sem sinal do detached HEAD.

git branch
feature01
* master
## Sinal do passeio no tempo.

git reflog
826f940 HEAD@{0}: checkout: moving from 095046c3927fe5fa9932d9d3d858e3128126b4fc to master

095046c HEAD@{1}: checkout: moving from master to HEAD@{4}

Vamos comear a ser ousados. Vamos voltar no passado, adicionar um arquivo,

commitar e ver o que acontece, como o histrico representado.
## Volta no tempo, aps commit que aumenta porqueLinux.txt.

git checkout HEAD@{6}
Note: checking out 'HEAD@{6}'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at 095046c... Novos argumentos.
## Baixa arquivo de dados da internet.

wget 'http://www.leg.ufpr.br/~walmes/data/pimentel_racoes.txt'
--(date +"%Y-%m-%d %H:%M:%S")-- http://www.leg.ufpr.br/~walmes/data/pimentel_racoes.txt

Resolving www.leg.ufpr.br (www.leg.ufpr.br)... ???.??.???.??
Connecting to www.leg.ufpr.br (www.leg.ufpr.br)|???.??.???.??|:80... connected.
Length: 217 [text/plain]
Saving to: pimentel_racoes.txt
0K 100% 68,9M=0s
(date +"%Y-%m-%d %H:%M:%S") (68,9 MB/s) - pimentel_racoes.txt saved [217/217]
pimentel_racoes.txt -> ../meu1repo/pimentel_racoes.txt
git status
HEAD detached at 095046c

Untracked files:
pimentel_racoes.txt
## Adiciona para registrar a incluso do arquivo.

git add pimentel_racoes.txt
git commit -m "Adiciona aquivo de dados de experimento com raes."
[detached HEAD f26d9b4] Adiciona aquivo de dados de experimento com raes.

create mode 100644 pimentel_racoes.txt
git status
HEAD detached from 095046c

## Log num formato grfico ASCII para mostrar o novo ramo.

git log --graph --oneline --decorate --date=relative --all
* 826f940 (master, feature01) Adiciona funo R para VIF.

| * f26d9b4 (HEAD) Adiciona aquivo de dados de experimento com raes.
|/
* 095046c Novos argumentos.
* 1aa33c3 Adiciona frase do Linux Torvalds.
* 8acac99 Lista de inicial de o porqu usar o Linux.
* 612c338 Cria arquivo com ttulo
No nosso projeto temos o master e o feature01 em igual condio, sem ne-

nhuma diferena. O commit recm feito indica um novo seguimento a partir
daquele onde adicionamos novos itens na lista. Vamos criar um novo ramo
porque atualmente estamos em um ramos suspenso (detached HEAD) que no
persistente.
git branch
* (HEAD detached from 095046c)

feature01
master
## Um novo ramo a partir do atual HEAD.

git checkout -b feature02
Switched to a new branch 'feature02'

git branch
feature01
* feature02
master
* 826f940 (master, feature01) Adiciona funo R para VIF.

| * f26d9b4 (HEAD -> feature02) Adiciona aquivo de dados de experimento com raes.
|/
Vamos explorar bem a funcionalidade. Vamos voltar para o feature01 e criar

mais coisas l. Voc j deve estar pensando que tudo isso absurdo e jamais
algum ficaria indo e voltando assim. Voc est certo, porm, quando o projeto
envolve mais pessoas, certamente as coisas iro bifurcar em algum ponto.
Diretrio existe.
Arquivo brasilCopa2014.txt j existe.
brasilCopa2014.txt -> ../meu1repo/brasilCopa2014.txt
wget 'http://www.leg.ufpr.br/~walmes/cursoR/geneticaEsalq/brasilCopa2014.txt'
--2015-12-17 09:29:04-- http://www.leg.ufpr.br/~walmes/cursoR/geneticaEsalq/brasilCopa2

Length: 1254 (1,2K) [text/plain]
Saving to: brasilCopa2014.txt
0K . 100% 69,6M=0s
2015-12-17 09:29:04 (69,6 MB/s) - brasilCopa2014.txt saved [1254/1254]
git add brasilCopa2014.txt

git commit -m "Arquivo sobre copa 2014 celeo brasileira."
[feature01 3044d9b] Arquivo sobre copa 2014 celeo brasileira.

create mode 100644 brasilCopa2014.txt
* 3044d9b (HEAD -> feature01) Arquivo sobre copa 2014 celeo brasileira.
* 826f940 (master) Adiciona funo R para VIF.
| * f26d9b4 (feature02) Adiciona aquivo de dados de experimento com raes.
|/
Agora nos temos o feature01 na frente do master e o feature02 ao lado. O con-

tedo dos dois ramos ter que ser incorporado ao master em algum momento
porque assim que funciona. Mas no h razes para preocupao pois o
propsito do Git justamente facilitar esse processo. Nesse caso, por exem-
plo, como as diferenas nos ramos consiste na adio de arquivos diferentes,
incorporar as modificaes no master ser uma tarefa simples para o Git. O
agravante quando em dois ramos (ou duas pessoas) o mesmo arquivo
modificado no mesmo intervalo de linhas. Nessa situao o merge nos arquivos
deve ser supervisionado e no automtico. Vamos incorporar as modificaes
dos ramos ao master ento.
## Volta para o master.

git checkout master
## Mescla o feature01.
Updating 826f940..3044d9b
Fast-forward
brasilCopa2014.txt | 22 ++++++++++++++++++++++
create mode 100644 brasilCopa2014.txt
## Mescla o feature02.
Merge made by the 'recursive' strategy.

pimentel_racoes.txt | 24 ++++++++++++++++++++++++
create mode 100644 pimentel_racoes.txt
* 039b7b6 (HEAD -> master) Merge branch 'feature02'

|\
| * f26d9b4 (feature02) Adiciona aquivo de dados de experimento com raes.
* | 3044d9b (feature01) Arquivo sobre copa 2014 celeo brasileira.
* | 826f940 Adiciona funo R para VIF.
|/
.
|-- brasilCopa2014.txt
|-- pimentel_racoes.txt
|-- porqueLinux.txt
|-- README.txt
`-- vif.R
3.6 Resolvendo conflitos
Agora vamos de propsito mostrar uma situao em que no possvel fazer o

merge automaticamente. Vamos criar um conflito. Para isso vou criar um ramo
novo, modificar o arquivo na ltima linha e commitar. Vou voltar par ao master
e fazer o mesmo mas vou usar um texto diferente para incluir no arquivo. J
que os ramos feature01 e feature02 no so mais necessrios, podemos remov-
los. No entanto, eles permanecem na histria do projeto e poder ressurgir se
voc voltar no tempo.
## Remove ramos.
git branch -d feature01
git branch -d feature02
git branch
Deleted branch feature01 (was 3044d9b).

Deleted branch feature02 (was f26d9b4).
* master

3.6. RESOLVENDO CONFLITOS 49
* 039b7b6 (HEAD -> master) Merge branch 'feature02'

|\
| * f26d9b4 Adiciona aquivo de dados de experimento com raes.
* | 3044d9b Arquivo sobre copa 2014 celeo brasileira.
|/
Agora vou criar um novo ramo, adicionar um arquivo e encurtar o nome das
colunas no cabealho.
## Muda para um ramo criado na hora.

git checkout -b feature03
Switched to a new branch 'feature03'
## Baixa o arquivo.
wget 'http://www.leg.ufpr.br/~walmes/data/bib1.txt'
--2015-12-17 09:29:04-- http://www.leg.ufpr.br/~walmes/data/bib1.txt

Length: 535 [text/plain]
Saving to: bib1.txt
0K 100% 35,0M=0s
2015-12-17 09:29:04 (35,0 MB/s) - bib1.txt saved [535/535]
## Mostra as 4 primeiras linhas.

head -4 bib1.txt
REPT VARI BLOC Y

1 1 1 20
1 2 1 18
1 3 2 15
Ao encurtar o nome para quatro dgitos, fica assim.
## Substitui o contedo da primeira linha pelos nomes truncados em 4

## dgidos e separados por tabulao. Etapa que voc pode fazer no seu
## editor de texto.
sed -i "1s/.*/rept\tvari\tbloc\ty/" bib1.txt
head -4 bib1.txt
rept vari bloc y

1 1 1 20
1 2 1 18
1 3 2 15
git add bib1.txt

git commit -m "Arquivo de experimento em BIB. Trunca cabealho 4 digitos."
[feature03 d8bab6c] Arquivo de experimento em BIB. Trunca cabealho 4 digitos.

create mode 100644 bib1.txt
Baixamos e modificamos o arquivo. Adicionamos e fizemos o registro das

modificaes. Agora vamos voltar ao master e baixar o arquivo tambm,
fazendo de conta que outra pessoa trabalhando no mesmo projeto, mas essa
pessoa vai passar a cabealho para caixa alta.
git checkout master
## Baixa o arquivo.
wget 'http://www.leg.ufpr.br/~walmes/data/bib1.txt'
Ao encurtar o nome para quatro dgitos, fica assim.
## Substitui o contedo da primeira linha pelo mesmo em caixa alta. Faa

## isso no seu editor de texto de preferido.
sed -i '1s/.*/\U&/' bib1.txt
head -4 bib1.txt
REPT VARI BLOC Y

1 1 1 20
1 2 1 18
1 3 2 15
git add bib1.txt

git commit -m "Arquivo de experimento em BIB. Cabealho em caixa alta."
[master 50dc261] Arquivo de experimento em BIB. Cabealho em caixa alta.

create mode 100644 bib1.txt

diff --git a/bib1.txt b/bib1.txt

index 1d05031..b5f5963 100644
--- a/bib1.txt
+++ b/bib1.txt
@@ -1,4 +1,4 @@
-REPT VARI BLOC Y
+rept vari bloc y
1 1 1 20
1 2 1 18
1 3 2 15
* d8bab6c (feature03) Arquivo de experimento em BIB. Trunca cabealho 4 digitos.

| * 50dc261 (HEAD -> master) Arquivo de experimento em BIB. Cabealho em caixa alta.
|/
* 039b7b6 Merge branch 'feature02'
|\
|/
## D mensagem de erro que informa o conflito.

Auto-merging bib1.txt
CONFLICT (add/add): Merge conflict in bib1.txt
Automatic merge failed; fix conflicts and then commit the result.
git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both added: bib1.txt
## `less` printa o contedo do arquivo mas `head` limita para 10 linhas.

less bib1.txt | head -10
<<<<<<< HEAD
REPT VARI BLOC Y
=======
rept vari bloc y
>>>>>>> feature03
1 1 1 20
1 2 1 18
1 3 2 15
1 4 2 16
1 5 3 14
Ento deu conflito e o Git informa que ele deve ser resolvido. Resolver o
conflito aqui significa abrir os arquivos com problema listados no Git status
e editar de tal forma a desconflitar. Nas regies de conflito o Git sinaliza
de forma especial, indicando por divisrias (<<<<<<<, ======= e >>>>>>>) as
verses no HEAD (ramo master) e no ramos a ser incorporado (feature03). Ento
vamos resolver o conflito sem favorecer ningum, ou seja, vamos encurtar para
4 dgitos e manter caixa alta. Dessa forma o aquivo fica assim.
## Arquivo depois da edio que resolve o conflito.

head -6 bib1.txt
REPT VARI BLOC Y

1 1 1 20
1 2 1 18
1 3 2 15
1 4 2 16
1 5 3 14
git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
Unmerged paths:
(use "git add <file>..." to mark resolution)
both added: bib1.txt
git add bib1.txt

git commit -m "Resolve conflito, trunca com caixa alta."
[master 9536074] Resolve conflito, trunca com caixa alta.
git status
On branch master
* 9536074 (HEAD -> master) Resolve conflito, trunca com caixa alta.
|\
| * d8bab6c (feature03) Arquivo de experimento em BIB. Trunca cabealho 4 digitos.
* | 50dc261 Arquivo de experimento em BIB. Cabealho em caixa alta.
|/
* 039b7b6 Merge branch 'feature02'
|\
|/
git reflog
9536074 HEAD@{0}: commit (merge): Resolve conflito, trunca com caixa alta.
50dc261 HEAD@{1}: commit: Arquivo de experimento em BIB. Cabealho em caixa alta.
039b7b6 HEAD@{2}: checkout: moving from feature03 to master
d8bab6c HEAD@{3}: commit: Arquivo de experimento em BIB. Trunca cabealho 4 digitos.
039b7b6 HEAD@{4}: checkout: moving from master to feature03
039b7b6 HEAD@{5}: merge feature02: Merge made by the 'recursive' strategy.
3044d9b HEAD@{6}: merge feature01: Fast-forward
826f940 HEAD@{7}: checkout: moving from feature01 to master
3044d9b HEAD@{8}: commit: Arquivo sobre copa 2014 celeo brasileira.
826f940 HEAD@{9}: checkout: moving from feature02 to feature01
f26d9b4 HEAD@{10}: checkout: moving from f26d9b4eaf6e2050d137009ab67310f8ecb4a5b1 to feature02
f26d9b4 HEAD@{11}: commit: Adiciona aquivo de dados de experimento com raes.
826f940 HEAD@{13}: checkout: moving from 095046c3927fe5fa9932d9d3d858e3128126b4fc to master

Captulo 4
Projetos Remotos
Nos captulos anteriores descrevemos como instalar o Git e ter projetos versio-
nados. No entanto, o uso do Git at ento foi apenas local. Os arquivos eram
mantidos na sua mquina de trabalho e disponveis s para voc.
Os recursos do Git, como o desenvolvimento em branches, permite que vrios
segmentos sejam conduzidos de forma independente e no futuro, quando
apropriado, reunidos em um nico branch. Isso exatamente o que precisamos
para trabalhar em equipe, certo? Se cada colaborador pudesse ter um ramo
separado do projeto para trabalhar, todos poderiam trabalhar simultaneamente.
Quando oportuno, bastaria fazer merges para reunir o trabalho. A questo :
como deixar o projeto disponvel para os colaboradores?
A resposta simples: mantenha o projeto em um servidor onde os colabora-
dores tenham acesso. Isso inclusive vai permitir que voc acesse o projeto de
vrias outras mquinas, como o notebook de casa e o desktop do escritrio.
4.1 Repositrio remoto pessoal

O repositrio remoto serve de centro do seu repositrio Git. Como ele est em
um servidor que voc tem acesso, voc pode compartilhar o repositrio com
outras mquinas, clonando de l. Ele serve como backup do repositrio.
Aqui no se trabalha em colaborao mas o processo permite acessar o reposi-
trio, transferir arquivos de vrias mquinas suas.
## Autenticar no servidor (logar).

ssh eu@servidor
## Verificar se a mquina tem o Git, se no instalar.

git --version
## Criar um diretrio para conter o projeto.

mkdir -p ~/meusProjetos/meu1repo
55
56 CAPTULO 4. PROJETOS REMOTOS
cd ~/meusProjetos/meu1repo
## Comear um projeto Git remoto. Note a opo --bare.

git --bare init
Apenas isso precisa ser feito no servidor. Voc no cria nenhum arquivo
pelo servidor. Inclusive, muitos dos comandos Git, como git status no
funcionam para repositrio iniciados com a opo git --bare init.
Caso queira, voc tambm pode usar git init. A diferena entre eles s
onde ficam os arquivos do versionamento. Com git init, um diretrio oculto
.git/ o repositrio Git e os arquivos de trabalho, como o README.md, ficam
ao lado dele na estrutura de diretrio. Com git --bare init o contedo
do repositrio Git fica na raiz. Essa ltima opo justamente para criar
repositrios remotos que vo justamente manter a parte repositrio e no os
arquivos.
git init git --bare init

. .
|-- .git |-- branches
| |-- branches |-- config
| |-- config |-- description
| |-- description |-- HEAD
| |-- HEAD |-- hooks
| |-- hooks |-- info
| |-- info |-- objects
| |-- objects +-- refs
| +-- refs
+-- README.md
Uma vez iniciado o repositrio no servidor, todo trabalho passa ser local. a
vez de adicionar o endereo do diretrio no servidor e transferir arquivos.
## Agora na sua mquina local, adicione o endereo do remoto.

git remote add eu@server:~/meusProjetos/meu1repo
## Exibir os endereos remotos.

git remote -v
Esse endereo pode ter IP, porque na realidade, todo servidor tem um IP. Por
exemplo, o servidor do github.com tem o IP 192.30.252.129. Para saber o IP
s dar um ping no endereo.
ping github.com
ping gitlab.com
ping google.com
ping cran.r-project.org
4.1. REPOSITRIO REMOTO PESSOAL 57
Normalmente, servidores de escritrio no tem um endereo nominal, apenas

o IP (numrico). necessrio registrar domnio para ter nominal.
## Agora na sua mquina local, adicione o endereo do remoto.

git remote add eu@111.22.333.44:~/meusProjetos/meu1repo
Nesse processo, toda transferncia de arquivos vai pedir senha do seu usurio
no servidor. Para facilitar, pode-se trabalhar com chaves pblicas.
O arquivo id_rsa.pub a sua chave pblica. O id_rsa o seu par. RSA o
tipo de encriptao. O nome e caminho do arquivo e a encriptao podem ser
outros, depende do que voc escolher ao gerar o par de chaves. Normalmente
usa-se RSA e as chaves so criadas no diretrio ~/.ssh.
## Exibir chaves pblicas.

cat ~/.ssh/id_rsa.pub
## Caso no tenha, gerar.

ssh-keygen -t rsa -C "eu@dominio.com"
No servidor, o arquivo authorized_keys2 contm as chaves pblicas das m-

quinas com acesso permitido sem senha. Esse arquivo nada mais que uma
coleo de chaves. O contedo dele so as chaves das suas mquinas, ou das
mquinas de outros usurios, contedo do id_rsa.pub, uma embaixo da outra,
conforme o exemplo abaixo1 .
## àuthorized_keys` do servidor da Liga da Justia.

ssh-rsa IyBUrjvUdSMY... flash@justiceleague.org
ssh-rsa AAAAB3NzaC1y... batman@justiceleague.org
ssh-rsa Mdju17IdXhSd... superman@justiceleague.org
## Logar no servidor
ssh eu@111.22.333.44
## Criar o diretrio/arquivo para as chaves pblicas.

mkdir ~/.ssh
> authorized_keys2
Agora preciso transferir o contedo do seu arquivo local id_rsa.pub para o

authorized_keys2 que fica no servidor. O jeito mais simples de fazer isso
com transferncia scp mas a instruo ssh abaixo tambm resolve.
## Transfere arquivo para diretrio temporrio.

scp ~/.ssh/id_rsa.pub eu@111.22.333.44:/tmp
## Cola o contedo do *.pub no final do authorized_keys.

ssh eu@111.22.333.44\
1O Flash foi o primeiro a transferir as chaves para o servidor porque ele mais rpido
"cat /tmp/id_rsa.pub ~/.ssh/authorized_keys"
## Faz os dois passos anteriores de uma vez s.

ssh eu@111.22.333.44\
"cat >> ~/.ssh/authorized_keys2" < ~/.ssh/id_rsa.pub
4.2 Repositrio remoto coletivo
A nica diferena recomendamos a voc criar um novo usurio e adicionar

as chaves pblicas de todos os membros. Evite adicionar chaves pblicas para
usurios na sua conta porque isso expe seus documentos, alguma operao
desastrosa por parte de algum pode compromet-los. Por isso, crie um
usurio, por exemplo gitusers, para nesta conta manter o repositrio remoto.
Solicite que os colaboradores gerem as chaves pblicas e te enviem o arquivo

id_rsa.pub. Depois voc adiciona cada chave ao authorized_keys de conta
gitusers. Com chaves autorizadas, os colaboradores podem transferir arqui-
vos, podem logar no servidor mas no podem instalar nada, a menos que
voc passe a senha do usurio gitusers. Para crias usurios no servidor, voc
precisa de privilgios de admin.
## Logar na servidora.
ssh eu@servidor
## No servidor, criar uma conta para o projeto.

sudo adduser gitusers
Vamos assumir que voc tm os arquivos *.pub dos colaboradores no diretrio

/chaves devidamente identificados pelo nome deles. O comando abaixo
acrescenta as chaves deles uma embaixo da outra no authorized_keys.
## Entra no diretrio com os arquivos *.pub.

## Existem vrias: angela.pub, jhenifer.pub, ...
cd chaves
## Juntar as chaves em um nico arquivo.

cat *.pub > todos.pub
## Copiar o contedo do arquivo pro authorized_keys2.

ssh gitusers@111.22.333.44\
"cat >> ~/.ssh/authorized_keys2" < todos.pub
4.3. FLUXO DE TRABALHO COM REPOSITRIO REMOTO, DO CLONE AO PUSH59
4.3 Fluxo de trabalho com repositrio remoto, do

clone ao push
4.3.1 Git clone
Este comando usado para clonar um repositrio do servidor remoto para

um servidor local, caso voc queira copiar um repositrio que j existe para
realizar colaboraes em um projeto que queira participar. Voc ter acesso
a todos os arquivos e poder verificar as diferentes verses destes. Supondo
que sua equipe de trabalho possui uma biblioteca Git Teste Clone, onde so
armazenados todos os arquivos. Voc pode clonar estes arquivos para o seu
diretrio de trabalho e assim modific-los conforme deseja.
Exemplo:
git clone git@gitlab.c3sl.ufpr.br:pet-estatistica/TesteClone.git
Desta forma voc ter um diretrio TesteClone em seu computador, onde

estaro todos os arquivos do projeto nele.
Voc tambm ter a opo de clonar o repositrio TesteClone em um dire-

trio diferente do padro Git, que no prximo exemplo denominaremos de
DirTeste:
Exemplo:
git clone git@gitlab.c3sl.ufpr.br:pet-estatistica/TesteClone.git DirTeste
4.3.2 Git Push
Aps clonar e realizar contribuies ao projeto, voc pode envi-los para

o repositrio remoto. Estes arquivos, aps o Git push, estaro prontos para
serem integrados ao projeto com o merge. Usado para transferncia de arquivos
entre repositrio local e o servidor remoto. Como o nome j diz, o comando
empurra os arquivos para o servidor remoto. No exemplo abaixo enviaremos
a ramificao Branch Master para o servidor chamado origin:
Exemplo:
git push origin master
importante ressaltar que se dois usurios clonarem ao mesmo tempo, realiza-

rem modificaes e enviarem os arquivos atualizados ao repositrio utilizando
o Git push, as modificaes do usurio que realizou o push por ltimo sero
desconsideradas.
4.3.3 Git Pull
Para obter todos os arquivos presentes no projeto, voc pode importar os

arquivos do branch master. Toda vez que voc utilizar o Git pull a ltima
verso de todos os arquivos estaro no seu diretrio. Tambm usado para
transferncia de arquivos, o comando puxa os arquivos do servidor remoto
para o repositrio local e faz o merge do mesmo, fundindo a ltima verso
com a verso atualizada.
Exemplo:
git pull origin master
4.3.4 Git fetch
Assim como o comando Git pull, o Git fetch transfere arquivos do reposit-
rio remoto para o local, porm ele no realiza automaticamente o merge dos
arquivos transferidos, o usurio deve fazer o merge manualmente.
Exemplo:
git fetch origin master
Para verificar as modificaes realizadas entre verses de um arquivo basta

utilizar o comando git diff:
Exemplo:
git diff master origin/master
4.4 Listar branches locais/remotos
O comando git remote usado para verificar quais repositrios esto configu-
rados.
Exemplo: para retornar a lista de repositrios:
git remote
No comando acima possvel visualizar o remoto padro origin (URL SSH

para onde ser possvel enviar os seus arquivos).
Exemplo: para retornar o nome dos repositrios com a URL onde foram
armazenados:
git remote -v
4.5. ADICIONAR, RENOMEAR, DELETAR REMOTE 61
4.5 Adicionar, renomear, deletar remote
4.5.1 Adicionando repositrios remotos
O comando git remote add adiciona um repositrio remoto. No exemplo a

seguir ser adicionado um repositrio chamado MeuRepo ao qual ser vincu-
lado a URL git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git.
Usaremos como exemplo o projeto Apostila-git.
Exemplo:
git remote add MeuRepo \

git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git
## A lista de repositrios agora :

git remote -v
Pare acessar localmente o branch master do projeto Apostila-git ser usado

MeuRepo/master.
4.5.2 Obtendo informaes de um Remoto
Voc pode acessar as informaes de qualquer repositrio remoto com o

comando git remote show, que retornar a URL e os branches.
Exemplo:
git remote show origin
4.5.3 Renomeado Remotos
O comando git remote rename pode modificar o nome de um repositrio

remoto. A seguir o repositrio MeuReposer renomeado para RenameRepo.
Exemplo:
git remote rename MeuRepo RenameRepo
4.5.4 Removendo Remotos
Para remover remotos utilizado o comando git remote rm, agora ser remo-
vido o repositrio renomeado anteriormente RenameRepo.
Exemplo:
git remote rm RenameRepo
4.5.5 Deletar ramos no servidor
Quando houver um branch que no est sendo utilizado ou est concludo, h

a opo de exclu-lo do servidor. Se for necessrio apagar branches remotos,
podemos utilizar o comando a seguir:
Exemplo:
git push origin --delete <branch>
4.5.6 Clonar apenas um branch, commit ou tag.
possvel clonar apenas um branch e no o repositrio Git completo. Supondo

que no repositrio h um branch chamado MeuBranch dentro do repositrio
MeuRepo, clonaremos o branch.
Exemplo:
git clone -b MeuBranch --single-branch git://sub.domain.com/MeuRepo.git
O Git ainda permite clonar um commit ou tag.

Exemplo:
## Para uma tag:

git -e: //git.myproject.org/MyProject.git@v1.0#egg=MyProject
## Para um commit:
git -e: //git.myproject.org/MyProject.git@da39a3ee5e6b4b0d3255bfef95601890afd80709#egg=M
4.6 Criando um Repositrio Git

Primeiramente necessrio ter acesso a um servidor Linux com chave SSH, no
qual voc poder ter seus repositrios. definido um diretrio no qual ser
armazenado o repositrio remoto. No prximo exemplo preciso criar um
repositrio remoto chamado MeuRepo e o armazenar em um diretrio ~/git:
Exemplo:
# Para criar um diretrio git na sua home:

mkdir ~/git
# Para criar um repositrio git:
mkdir MeuRepo.git
# Para definir MeuRepo como um repositrio remoto:
git --bare init
4.7. GIT NO SERVIDOR 63
As configuraes do servidor esto completas. A partir de agora voc pode

realizar os primeiros comandos para iniciar o repositrio criado.
4.7 Git no servidor

Primeiramente, para configurar o Git no Servidor e configurar os protocolos,
clonaremos o repositrio existente em um repositrio limpo. Observao: voc
poder colocar um repositrio no Servidor se este no contm um diretrio de
trabalho.
Exemplo:
git clone --bare MeuRepo MeuRepo.git
Acima foi criado um repositrio limpo MeuRepo.git, no qual est armazenada

a cpia de todos os arquivos do diretrio Git.
Aps este primeiro passo o repositrio limpo ser colocado no Servidor e confi-
gurado os protocolos. No exemplo abaixo, supondo que voc tem configurado
um servidor git.servidor.com, e um diretrio /dir/gitno qual voc quer
armazenar seus repositrios. Ao copiar o seu repositrio limpo, voc pode
configurar seu novo repositrio.
Exemplo:
scp -r MeuRepo.git usuario@git.example.com:/dir/git
Agora o repositrio pode ser clonado por outros usurios, que podem ter
acesso de escrita e de envio de arquivos push no diretrio.
git clone usuario@git.example.com:/dir/git/MeuRepo.git
4.8 Configurao de Conexo SSH com Servidor

O Git possibilita ao usurio realizar uma chave SSH que far uma conexo
segura da sua mquina com o servidor. Para isso comeamos com o seguinte
comando no terminal:
Exemplo:
## Gerando uma chave ssh

ssh-keygen -t rsa -C "usuario@email.com"
A partir deste comando, ser possvel alterar o diretrio onde ser salva a
chave SSH. O usurio tem a opo de permanecer com o diretrio padro,
para isso basta apertar Enter. A partir disso, so criados dois arquivos no
diretrio, o id_rsa e o id_rsa.pub. Aps escolher o diretrio onde sero
salvos os arquivos, voc ter a opo de digitar uma senha ou deixar o espao
em branco.
Para visualizar a chave basta digitar o seguinte comando:
Exemplo:
A chave est no arquivo id_rsa.pub. O usurio deve copiar o texto deste

arquivo na ntegra. Para gerar a conexo ssh com o servidor, deve visitar o site
https://gitlab.c3sl.ufpr.br/profile/keys e clicar em Add SSH Key. necessrio
escrever um ttulo para a sua nova chave, no campo key colar o texto copiado
do arquivo id_rsa.pub e adicionar sua nova chave.
Para checar a configurao da sua mquina com o servidor basta realizar o
seguinte comando:
Exemplo:
ssh -T git@gitlab.c3sl.ufpr.br
Configurando o servidor
Agora ser abordado como configurar o acesso SSH do ponto de vista do
servidor. Voc precisa criar um usurio Git e um diretrio .ssh para este
usurio.
Exemplo: criar usurio e diretrio.
sudo adduser git

su git
cd
mkdir .ssh
Agora, voc ter um arquivo chamado authorized_keys onde ser adicionado

uma chave pblica de algum desenvolvedor. Aps obter chaves de alguns
usurios, voc pode salv-las no arquivo authorized_keys, como no exemplo
a seguir.
Exemplo:
## Chave do primeiro usurio.

cat /tmp/id_rsa1.pub >> ~/.ssh/authorized_keys
## Chave do segundo usurio.

cat /tmp/id_rsa2.pub >> ~/.ssh/authorized_keys
...
Depois de armazenar as chaves dos usurios, basta criar um repositrio limpo

(sem um diretrio de trabalho) para eles. Como visto anteriormente:
Exemplo:
4.8. CONFIGURAO DE CONEXO SSH COM SERVIDOR 65
cd/dir/git
mkdir NovoProjeto.git
cd NovoProjeto.git
git -bare init
Agora os usurios, cujas chaves foram salvas no arquivo authorized_keys

podem compartilhar arquivos no repositrio com os comando git init, git
add, git commit, git remote add e git push origin master.
Captulo 5
Servios Web para Projetos

Git
5.1 Servios Web para Git
No captulo anterior vimos como configurar um repositrio remoto em um

servidor. Esse procedimento possibilita trabalho em equipe pois centraliza
o repositrio remoto em um servidor que todos tm acesso. Assim, todos
podem clonar, criar branches, subir as contribuies, etc. Apesar do servidor
centralizar o trabalho de todos os usurios, estes tero que se comunicar e fazer
a gesto de tarefas sobre o projeto de outra forma, como por e-mail direto, lista
de emails/discusso ou chats coletivos. Para que um desenvolvedor veja o
que os outros fizeram, ele ter que periodicamente dar fetch, ver os branches
do repositrio, navegar no histrico de commits, ver diffs entre arquivos. Se
por um lado existe recurso para um fluxo de desenvolvimento orientado dessa
forma, tambm existem recursos para tornar o trabalho coletivo mais simples e
centralizado. Eles so os servios web para projetos Git.
O Git tem vrios servios web voltados para ter um local que centralize o
projeto bem como oferea recursos administrativos e colaborativos. Esses
servios possuem contas free, alguns planos pagos e diversos recursos para
todo tipo de projeto e equipe.
Os objetivos desse captulo so: apresentar os servios web para repositrios

Git, descrever suas principais caractersticas, descrever como criar e configurar
uma conta e conectar-se a um repositrio local. Alm disso, o workflow bsico
que considera servies web ser discutido, enfatizando os principais recursos
desses servios voltados colaborao.
67
68 CAPTULO 5. SERVIOS WEB PARA PROJETOS GIT
5.1.1 GitHub
O GitHub1 um servio web para hospedagem, gesto e compartilhamento

de repositrios Git que oferece recursos para desenvolvimento e colaborao.
Build software better, together. o principal slogan do GitHub, justamente
para enfatizar o seu principal compromisso: dar suporte ao desenvolvimento
colaborativo.
Figura 5.1: Octocat o mascote do GitHub.
O GitHub foi fundado em 8 de Fevereiro de 2008, em So Francisco, por quatro

pessoas: Tom Preston-Werner, Chris Wanstrath, PJ Hyett e Scott Chacon. Antes
de terminar 2015, o GitHub j havia ultrapassado a marca de 10 milhes de
usurios. De acordo com o http://githut.info/, no quarto trimestre de 2014
haviam 22 milhes de repositrios. A linguagem JavaScript teve o maior
nmero de repositrios ativos (>320 mil) e total de pushes, enquanto que a
linguagem R teve o maior nmero de novas cpias por repositrio (6.45).
Diferente da forma tradicional de usar o Git, por linha de comando, o GitHub
um servio web com interface grfica repleta de funes para o desenvol-
vimento e acompanhamento de um projeto Git. Tais recursos vo desde
administrar tarefas at permitir a colaborao de outras pessoas, mesmo sendo
desconhecidas. Dentre os principais recursos disponveis, tm-se:
README: um arquivo que funciona como capa do seu repositrio. O

seu contedo texto escrito em linguagem de marcao (Markdown, RST,
Textile, Org, etc) renderizada para exibio pelo GitHub. Como capa, o
contedo do README est na home do projeto e serve para informar o
visitante dos objetivos do repositrio, seus desenvolvedores, instrues
de instalao/uso e formas de colaborao.
Wiki: a Wiki de cada repositrio um conjunto de pginas que serve
para divulgao e documentao do repositrio. Estas tambm so
escritas em linguagem de marcao, tornando fcil e rpida a escrita pelo
desenvolvedor e simples para o visitante ler e navegar. Como a Wiki
tambm um repositrio Git, ela pode inclusive ser editada por meios dos
recursos de edio do prprio GitHub, alm de ser versionada. Com isso,
no diferente do restante, a edio da Wiki tambm colaborativa.
1 https://github.com/
5.1. SERVIOS WEB PARA GIT 69
Issues: pelos issues so feitas as notificaes de bug e gerenciamento de

tarefas. Os usurios criam issues para notificar um bug encontrado de
forma que ele possa ser rapidamente corrigido. Criar issues tambm serve
como ferramenta de administrao de tarefas nas quais eles descrevem
algo a ser feito por algum.
Milestones: so pedras de milha, ou seja, marcam um ponto a ser alcan-
ado. So usadas para descrever o que precisa ser desenvolvido para que
ocorra uma mudana de verso e estabelecer um prazo para concluso,
por exemplo. As milestones agrupam issues que indicam as etapas a serem
percorridas.
Pull request ou merge request (MR): uma requisio de fuso. Os mem-
bros da equipe fazem suas contribuies em ramos de desenvolvimento
e ao concluir pedem um MR pela interface. O responsvel por avaliar o
MR pode ver os diffs nos arquivos e fazer o merge direto pela interface,
de dentro do servio sem precisar baixar (fetch) o ramo, aplicar o merge
(merge) e subi-lo (push). Ento os desenvolvedores no precisam inter-
romper o trabalho local para fazer um merge j que ele pode ser feito no
servio sem modificaes no workspace.
Fork: uma forma de se fazer uma cpia do projeto de algum para
livremente experimentar modificaes sem afetar o projeto original. A
cpia vem para a sua conta e funciona como qualquer outro repositrio
seu. A ideia do fork dar liberdade de contribuio (no supervisionada)
a qualquer pessoa interessada de modo que esta possa submeter as
contribuies para a origem (por MR) ou at mesmo usar como ponto de
partida para um novo projeto.
De acordo com Klint Finley2 , fork e MR so os recursos que tornam o GitHub

to poderoso. Quando o mantenedor recebe um MR ele pode ver o perfil do
contribuidor onde esto listados todos os projetos no qual este contribuiu. Ao
aceitar o MR, acrescentado mais uma colaborao a reputao do colaborador.
Esse mecanismo, ento, beneficia as duas partes.
Alm dessas caractersticas chave, o GitHub permite que voc acompanhe

(watch) e favorite (star) repositrios. Tambm d para seguir pessoas e participar
de organizaes (grupo de usurios) que podem ter repositrios prprios, ideal
para projetos em equipe.
O perfil de cada usurio registra suas atividades em todos os projetos e em cada

um pode-se acompanhar as contribuies de cada colaborador. Nos repositrios
pode-se navegar pelo histrico de commits, filtr-los por colaborador, ver as
modificaes no cdigo (diffs) comparando commits e branches.
O GitHub no hospeda apenas cdigo fonte mas sim todo e qualquer arquivo
que voc tenha sob versionamento. possvel hospedar dados, por exemplo,
em formato texto (csv, txt), e disponibiliz-los por meio da URL para download
ou leitura direta. Para usurios de R, essa uma caracterstica que permite no
apenas disponibilizar dados, mas tambm colees de funes que podem ser
carregadas com um source().
2 http://techcrunch.com/2012/07/14/what-exactly-is-github-anyway/
Com o plano free do GitHub, voc pode ter inmeros repositrios pblicos,
inmeros colaboradores, ter o fork de quantos repositrios quiser e participar
de quantas organizaes precisar. Para ter repositrios privados, o plano
mais bsico custa U$ 7 por ms e d direito 5 repositrios. Existem outros
planos individuais, e tambm planos organizacionais, para todos os tamanhos
de projeto e equipe. Alm dessas opes, pode-se ter o GitHub em um
servidor prprio, o GitHub Interprise3 , com recursos e vantagens alm das j
mencionadas
Para muitos programadores, o GitHub uma fonte de conhecimento. L voc
encontra scripts de todas as linguagens de programao. Voc pode livremente
estudar o cdigo dos repositrios, ver como o cdigo evoluiu commit aps
commit e acompanhar como um bug foi resolvido.
Qualquer pessoa, mesmo sem perfil no GitHub, pode clonar um repositrio
pblico. O GitHub reconhece 382 linguagens que compreendem as de pro-
gramao (293: C++, Python, R, JavaScript), as de markup (34: HTML, TeX,
MarkDown), as de dados (40: JSON, SQL, XML, csv) e aplica os realces de
cdigo (highlights) que facilitam a sua compreenso.
O GitHub o servio web para Git mais popular quanto ao nmero de projetos
hospedados. No entanto, existem servios com as mesmas funcionalidades
e at com algumas que o GitHub no oferece no plano bsico. O GitLab e o
Bitbucket esto entre os 5 mais populares e permitem, por exemplo, ter alguns
repositrios privados com a conta free.
Como hospedamos nossos projetos coletivos do PET-Estatstica no GitLab do
C3SL4 , no podemos deixar de falar sobre ele.
5.1.2 GitLab
O GitLab5 , assim como o GitHub, um servio web para repositrios Git. O

GitLab um projeto open source desenvolvido em Ruby que teve incio em 2011
pelo ucraniano Dmitriy Zaporozhets. Em 2013, a Companhia GitLab tinha uma
equipe de 11 funcionrios e mais de 10 mil organizaes usando o servio.
O GitLab, alm de ser um servio gratuito (com planos extras), tambm um
programa que voc pode instalar em servidor local para ter seus repositrios
na intraweb. Esse o caso do GitLab do C3SL e do GitLab do LEG6 .
O GitLab oferece todos os recursos do GitHub7 . No entanto, com uma conta
gratuita no http://gitlab.com, voc pode ter alm de repositrios pblicos e
colaboradores, ilimitados repositrios privados sem pagar por nada. Isso faz
do GitLab.com o lugar certo para pequenas equipes com pouco recurso ou que
desenvolvem trabalhos sem fins lucrativos, como o caso de colaborao em
cdigo para anlise de dados para publicao cientfica. Atualmente existem
mais de 69 mil projetos pblicos e 5840 grupos abertos no GitLab.com.
3 https://enterprise.github.com
4 https://gitlab.c3sl.ufpr.br/explore
5 https://about.gitlab.com/
6 http://git.leg.ufpr.br/explore
7 http://technologyconversations.com/2015/10/16/github-vs-gitlabs-vs-bitbucket-server-formerly-stash
5.2. CRIAR UM PERFIL 71
Figura 5.2: O guaxinim (*raccoon* em ingls) o mascote do GitLab.
A verso paga do GitLab, Enterprise Edition (EE), tem um preo menor que a
equivalente do GitHub.
A verso gratuita do GitLab para servidores, a Community Edition (CE), pode ser
instalada em servidores Linux, Windows, mquinas virtuais e servidores na nu-
vem, alm de outras opes. Os endereos https://gitlab.c3sl.ufpr.br/explore
e http://git.leg.ufpr.br/explore so o GitLab CE para servidores rodando no
C3SL (Centro de Computao Cientfica e Software Livre) e LEG (Laboratrio
de Estatstica e Geoinformao). Estes GitLabs do suporte colaborao em
cdigo dentro dos departamentos de Informtica e Estatstica para alunos e
professores (C3SL) e para a equipe e colaboradores do LEG.
Em termos financeiros, custa menos um servidor na nuvem da Digital Ocean8
com o GitLab CE (U$ 5/ms) do que ter uma conta para repositrios privados
no GitHub (U$ 7/ms) por 5 repositrios privados). No entanto, conforme
j mencionamos, pequenas equipes podem ter repositrios privados na conta
gratuita do GitLab.com.
Alm das caractersticas essenciais e comuns aos demais servios, como issues,
fork, merge requests, wiki e snippets, o GitLab tem 1) 5 nveis de acesso aos
repositrios (owner, master, developer, report e guess), 2) reviso comentada de
cdigo nos diffs, 3) importao repositrios de outros servios, 4) adio de web
hooks e 5) integrao contnua nativa a partir da verso 8.0.
5.2 Criar um perfil
Criar uma conta no Github to simples como uma conta de e-mail ou numa
rede social. Acesse o endereo https://github.com/join para preencher seus
dados pessoais e escolher um plano. Nenhum dos planos tem limitao quanto
ao nmero de repositrios ou colaboradores. O que muda a quantidade
de repositrios privados. No plano free, s so criados repositrios pblicos
enquanto que nos planos pagos, o menor deles permite 5 repositrios privados
8 https://www.digitalocean.com/community/tutorials/how-to-use-the-gitlab-one-click-install-image-to-manage-git-repositories
por um custo de U$ 7 por ms. Acesse https://github.com/pricing para mais

detalhes.
Ao preencher o formulrio de criao de conta, voc receber um e-mail com
uma url de ativao. Se optar por planos pagos, ter que informar o nmero
do carto de crdito para que seja feito o pagamento mensalmente.
Para criar uma conta gratuita no GitLab, acesse https://gitlab.com/users/
sign_in. Os servios GitLab que usamos so instalaes em servidoras prprias
(do C3SL e do LEG), no entanto, a interface do usurio a mesma, com exceo
de alguns privilgios administrativos.
5.2.1 Habilitar comunio
Uma vez criada uma conta, necessrio habilitar a comunicao entre sua
mquina e o (servidor do) GitHub. A comunicao feita com protocolo SSH
(Secure Shell), o qual j usamos no captulo anterior para hospedar o repositrio
em um servidor remoto.
Para relembrar, a maioria dos servidores suporta a autenticao por SSH.
Para que a conexo entre mquinas seja automtica, ou seja, sem precisar
fornecer usurio e senha a cada acesso/transferncia, usamos o recurso de
pares de chaves. Este serve para fazer a mquina remota (servidor) reconhecer
a mquina local (sua mquina) via autenticao do par de chaves. como se o
servidor fosse um cadeado e a sua mquina local tem a chave que o abre. Uma
vez que as chaves so pareadas e compatveis, ocorre o acesso ou transferncia
de arquivos.
Para gerar as chaves pblicas, voc precisa executar:
## Gera chaves pblicas.

ssh-keygen -t rsa -C "seu_email@seu.provedor"
## Batman gerando chaves pblicas.

ssh-keygen -t rsa -C "batman@justiceleague.org"
Generating public/private rsa key pair.

Enter file in which to save the key (/home/batman/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/batman/.ssh/id_rsa.
Your public key has been saved in /home/batman/.ssh/id_rsa.pub.
The key fingerprint is:
66:c1:0b:3a:94:25:83:00:81:9f:40:26:f7:aa:af:3a batman@justiceleague.org
The key's randomart image is:
+--[ RSA 2048]----+
| |
~MMMMMMMMMMMM MMMMMMMMMMMM~
.MMMMMMMMM. MMM .MMMMMMMMM.
MMMMMMMMMMMMMMMMMMMMMMMMMMM
Figura 5.3: Printscreen da pgina de configuraes pessoais do GitHub. No

menu SSH Keys pode-se ver e adicionar chaves pblicas.
MMMMMMMMMMMMMMMMMMMMMMMMM
.MMMMMMMMMMMMMMMMMMMMMMMMM.
.MMMMMMMMM.
.MMM.
M
| |
+-----------------+
O endereo padro para os arquivos criados o diretrio ~/.ssh/. Os arquivos

sero reescritos caso j existam arquivos de chaves pblicas l. Todo novo
par de chaves nico. Ento, se voc reescreveu os arquivos anteriores, ter
que atualizar as chaves pblicas em todos os servios web que fazem uso
desse recurso e com todos os servidores com o qual voc tem autenticao por
chaves.
Acesse https://github.com/settings/ssh para ento adicionar chaves pblicas
(Figura 5.3) ao seu perfil. Clique em Add SSH key , cole o contedo copiado
do arquivo *.pub no campo key. No campo Title identifique a mquina
correspondente quela chave. Use, por exemplo, laptop ou trabalho para
facilitar o reconhecimento. comum trabalhar-se com mais de um mquina,
como uma em casa e outra no trabalho.
Para testar a comunicao entre o GitHub e a sua mquina, execute:
## Testa comunio. Retorna um "Welcome!" em caso positivo.

ssh -T git@github.com
## Se falhar, habilite o modo verbose para rastrear o erro.

ssh -vT git@github.com
No GitLab, o cadastro de chaves pblicas um processo semelhante. Uma

vez autenticado, acesse https://gitlab.c3sl.ufpr.br/profile/keys para adicionar

chaves pblicas. Para testar a comunicao entre o GitLab e a sua mquina,
execute:
## Testa comunio. Retorna um "Welcome!" em caso positivo.

ssh -T git@gitlab.c3sl.ufpr.br
## Se falhar, habilite o modo verbose para rastrear o erro.

ssh -vT git@gitlab.c3sl.ufpr.br
Lembre-se de que o endereo gitlab.c3sl.ufpr.br corresponde ao servio

GitLab disponibilizado pelo C3SL. Caso voc esteja fazendo a conta no Gi-
tLab.com, o endereo muda de acordo.
5.2.2 Gerenciar repositrios
GitHub
A comunicao com o GitHub acabou de ser estabelecida. Agora podemos
criar repositrios e comear a mostrar nosso trabalho para o mundo e colaborar
de forma eficiente.
No canto superior direito das pginas do GitHub existe um cone + que
permite criar um novo repositrio ou uma nova organizao. Clique em
New repository ou acesse o endereo https://github.com/new. Na janela que
abrir, d um nome para o seu projeto e adicione uma breve descrio ele
(Figura 5.4). Na etapa seguinte, defina o nvel de visibilidade: pblico ou
privado. Lembre-se que os planos free s permitem repositrios pblicos. Ao
clicar em privado voc passar pelos formulrios para efetuar pagamento.
Para criar o projeto dentro de uma Organizao, selecione a Organizao na
drop list que fica no campo Owner, a esquerda do campo para o nome do
repositrio.
Voc pode inicializar o repositrio com um arquivo README.md, o que alta-
mente recomendado. Como j mencionamos, esse arquivo a capa do seu
repositrio e serve para documentar o seu objetivo, formas de colaborao,
colaboradores, formas de instalao/uso.
Voc pode editar o arquivo README.md (ou qualquer outro) no prprio GitHub.
As modificaes que fizer devem ser commitadas para serem salvas. O arquivo
README.md, que linguagem de marcao MarkDown, automaticamente
renderizado pelo GitHub fazendo com que urls sejam clicveis e cdigos
estejam em ambientes de fonte monoespao, alm de ter ttulos com tamanho
de fonte apropriado.
Depois de criar o repositrio, voc j pode clon-lo para trabalhar localmente. O
endereo do repositrio composto pelo seu nome de usurio (ou organizao)
e nome do repositrio. O repositrio bat-rangue da conta do batman pode ser
clonado com:
Figura 5.4: Janela para a criao de um novo repositrio no GitHub.

## Clone pelo protocolo ssh. Requer chaves pblicas.

git clone git@github.com:batman/bat-rangue.git
Pode-se clonar repositrios pelo protocolo http (Hypertext Transfer Protocol).

Em geral, para clonar repositrios de outros usurios e fazer testes, usa-se http.
Embora voc possa usar http nos seus repositrios, prefira o SSH. Com http,
o endereo passa a ser:
git clone https://github.com/batman/bat-rangue.git
Por padro, ao clonar o repositrio, um diretrio de mesmo nome criado com

o projeto em seu interior. Em caso de preferir outro nome para esse diretrio,
por exemplo, bat-bumerangue, use:
git clone https://github.com/batman/bat-rangue.git \

bat-bumerangue
Existe outra situao que quando voc j tem repositrio Git no qual j
est trabalhando e quer t-lo no GitHub. Nesse caso, voc vai criar um novo
repositrio mas no ir clon-lo, apenas copie a url que usaria para clon-lo.
No repositrio local, adicione essa url como endereo do servidor remoto e
faa um push. Vamos supor que o repositrio seja um artigo cientfico de
nome Artigo. Ao criar o repositrio com esse nome no GitHub, o endereo
fica git@github.com:fulano/Artigo.git. Ento s adicionar esse endereo
como origin do projeto Git:
## Adiciona endereo de "origin" ao repositrio.

git remote add origin git@github.com:fulano/Artigo.git
## Sobe o contedo do repositrio.

git push -u origin master
O seu projeto configurado em Settings . Para renomear, deletar ou transferir o

projeto para outro usurio ou organizao, v em Options . Em Collaborators voc
administra os colaboradores do projeto. Para gerenciar os ramos de trabalho,
como proteger ou remover ramos, v em Branches . O uso de de servios web
configurado no Webhooks & services . O Deploy keys permite adicionar chaves
pblicas.
Vamos considerar um repositrio bem ativo para conhecermos um pouco mais
dos recursos do GitHub. O repositrio https://github.com/yihui/knitr (Figura
5.5) o stio de desenvolvimento do pacote knitr do R, o principal pacote para
a gerao de relatrios dinmicos. Nesse repositrio tem-se acesso aos fontes.
Na figura 5.5, logo abaixo do ttulo, tem-se quatro quantificadores:
commits: ao clicar neste item, tem-se o histrico de commits com autor,

mensagem e SHA1. possvel comparar estados dos arquivos (diff ) ao
clicar no SHA1.
Figura 5.5: Home de um repositrio no GitHub.
branches: este lista os branches do projeto, permite comparar ramos.

releases: documenta as modificaes de uma verso para outra e lista os
commits que tem tags. Essa uma fonte importante para saber as maiores
mudanas entre verses.
contributors: d um resumo das atividades dos colaboradores do projeto.
Na aba members tem-se uma lista de todos os usurios que fizeram o fork
do seu projeto. Falaremos de fork adiante.
No menu da direita existem links para acessos a mais informaes:
Code: esto visveis os diretrios e arquivos do projeto. Pode-se navegar

entre eles. Ao visualizar um arquivo, ele exibido com realces de acordo
com a linguagem para facilitar a compreenso. Ao abrir um arquivo, no
topo aparecem botes de exibio/ao: Raw para ver o arquivo cru,
sem renderizao e highlights. A url dessa exibio pode ser usada para
ler/baixar arquivos de dados ou scripts direto da web. Blame mostra
o arquivo com autor para cada poro do cdigo. O History mostra o
histrico de commits. Os dos cones seguintes permitem editar o arquivo
ou deletar.
Issues: permite criao e acesso aos issues do projeto. Dentro dessa pgina
tem-se acesso s Milestones, que so as colees de issues por tema.
Pull requests: o termo que o GitHub usa para requisio de merge.
Nesta pgina pode-se submeter uma requisio e navegar nas existentes.
Wiki: na Wiki de um repositrio normalmente feita uma documentao
mais detalhada do projeto. Pginas Wiki de um repositrio tambm so
repositrios Git, portanto, versionveis.
Pulse: d um resumo sobre a quantidade de issues presentes, fechados e
abertos bem como para as requisies de mescla. Mostra tambm um
resumo da atividade recente do repositrio.
Graphics: exibe grficos sobre a atividade no repositrio, como frequncia

de commits, total e por autor, instantes do dia de maior colaborao, etc.
Existem ainda mais coisas sobre o GitHub que no podemos deixar de comen-
tar: os recursos disponveis para colaborao. Nas sesses frente, trataremos
dos recursos de issue, fork e requisies de merge. Antes, no entanto, vamos
conhecer um pouco do GitLab, um servio web para projetos Git que pode ser
instalado no seu servidor.
O GitLab o servio que ns do PET usamos para colaborao em nossos
projetos. Alm disso, o que os alunos usam para fazerem seus trabalhos
e desenvolverem o TCC. O uso do Git como ferramenta de trabalho passou
ser estimulado no segundo semestre de 2015. Alm de reunir os alunos e
professores numa plataforma de colaborao eficiente, o conhecimento de Git
passa ser um diferencial no currculo.
GitLab
O GitLab concentra os acessos outras pginas em um menu do lado esquerdo.
Do lado direito pode haver informaes extras. O boto para criar um novo
repositrio fica no canto superior direito. Ao lado deste tem botes para ir
para pgina de configuraes, sair, ajuda e explorar o GitLab.
No menu da direita tem-se acesso aos projetos do usurio ( Yout Projects e
Starred Projects ) e aos grupos do qual participa ( Groups ). As entradas Milestones ,
Issues e Merge requests renem as informaes sobre todos os projetos do qual o
usurio participa.
Assim como acontece com outros servios web, na pgina inicial do projeto
exibido o arquivo de capa, o README. Centralizado na pgina encontra-se o
endereo para clonar o repositrio por SSH ou HTTP(S) e as principais entradas
esto no menu da direita:
Project: a pgina inicial;

Activity e Commits: listam a atividade (predominantemente commits);
Files: apresenta diretrios e arquivos, com opo de mudar o ramo;
Network: o estado de desenvolvimento dos ramos do projeto com uma
lista de todos os commits;
Graphs: contm a atividade de cada membro do projeto;
Milestones rene as marcas de milhas do projeto com progresso de cada
uma;
Issues: pode-se gerenciar os issues dos projetos;
Merge resquests: permite criao e acompanhamento das requisies de
mescla;
Members: faz a gesto da equipe de trabalho como adio e redefinio
dos nveis de acesso;
Labels so usados para classificar os issues - comum usar bug, fix, review.
Wiki: vai para a pgina Wiki do repositrio, onde possvel edit-la;
Settings: so feitas as configuraes gerais do projeto como definio
de nome, descrio, nvel de visibilidade e adio e Web Hooks. Nessa
mesma pgina pode-se renomear, transferir ou remover o projeto.
5.3. FLUXO DE TRABALHO 79
Agora que conhecemos um pouco da interface dos servios Git, podemos

descrever o procedimento de trabalho considerando tais interfaces.
5.3 Fluxo de trabalho

O fluxo de trabalho de um projeto Git local usando um servidor remoto foram
apresentados no captulo anterior. O fluxo com um repositrio Git mantido em
um servio, como o GitHub ou GitLab, no muda muito. A maior diferena
no sobre o uso de novas instrues Git mas sim a adoo de uma estratgia
de trabalho (workflow) baseada nos recursos desses servios, como as milestones
e issues. Esse modelos de trabalho sero descritos em um captulo frente.
O fluxo de trabalho com repositrios remotos, em termos de comandos, acres-
centa queles necessrios para se comunicar com o repositrio. Alguns desses
comandos, seno todos, j foram apresentados no captulo anterior a esse.
Ao considerar um servio web, voc pode comear um repositrio novo de
duas formas: localmente ou pelo servio.
Pelo servio, qualquer que seja, crie um novo repositrio. GitHub e GitLab
do instrues resumidas de como proceder logo que voc cria um novo
repositrio. Eles inclusive, incluem opes como criar um repositrio com
arquivo de README. Assim que criar, seu repositrio ter um endereo (SSH e
HTTP). Na sesso anterior, descremos o processo de criar e clonar o repositrio
e tambm de criar local e adicionar a url do repositrio remoto (origin).
Localmente o repositrio segue o ciclo normal de desenvolvimento que mini-
mamente contm as instrues git add e git commit. Os fluxos de trabalho,
em geral, preconizam o desenvolvimento a partir de branches de demanda cujo
contedo ser incorporado aos ramos permanentes (master, devel) quando
forem concludos. Abaixo ilustramos a sequncia de criar um ramo, desenvolv-
lo e por fim subir o seu contedo para o repositrio remoto, que nesse caso
mantido em um servidor web.
## Cria um ramo chamado issue#10.

git branch issue#10
## Muda do ramo atual para o recm criado.

git checkout issue#10
## Segue a rotina.
git add <arquivos>
git commit -m <mensagem>
## Sempre que quiser, suba o trabalho.

git push origin issue#10
Nessa rotina, consideramos issue#10 um issue criado na interface web para

atender uma demanda, como por exemplo, corrigir um bug. Da mesma forma
que o ramo default do Git o master, o repositrio remoto por default
chamado de origin, ento subimos o contedo desse ramo para o servidor

que mantm o repositrio sob o servio web.
No h limites para o nmero de ramos. Ramos podem ser locais, remotos ou
ambos. Quando voc cria um ramo, como nos comandos acima, ele um ramo
local. Quando voc sobre esse ramo, ele passa ter sua parte remota tambm. E
quando voc clona um repositrio, voc traz todos os ramos que ele possui,
que so ramos remotos. Ao escolher um ramo desse para trabalhar, ele passa a
ser tambm um ramo local. Segue abaixo, formas de listar os ramos do projeto.
## Lista os ramos locais.

git branch -l
## Lista os remostos.
git branch -r
## Lista todos (all).

git branch -a
Voc pode notar que ramos locais no tem prefixo e que ramos remotos tem
o prefixo origin/. Voc pode remover um ramo local mas manter sua parte
remota e pode tambm excluir esse ramo por completo de todo o sistema,
localmente e no servidor, conforme ilustram os cdigos abaixo.
## Remove um ramo local (no mais til).

git branch -d issue#10
## Remove sua cpia remota (no mais til tambm).

git branch -dr origin/issue#10
## Remove um ramo remoto na origem (duas formas).

git push origin --delete issue#10
git push origin :issue#10
At aqui nos referimos ao repositrio remoto como origin que o nome

default. No entanto, um projeto Git pode ter mais de um repositrio remoto.
Considere o caso simples de um repositrio para arquivos de uma disciplina.
Esse repositrio contm tanto lista de exerccios para os alunos como tambm
as provas com as solues. Para no entregar as provas de bandeja, o diretrio
de provas existe no ramo secret e enviado somente para um repositrio
privado chamado provas. J o contedo restante (lista de exerccios, notas de
aula, scripts), disponibilizado para os alunos, fica no ramo master, mantido
em um repositrio aberto chamado de origin.
Dois repositrios remotos tem endereos distintos pois so projetos distintos
no servio web. Voc pode ter a parte pblica do projeto (origin) no GitHub e
a parte privada, as provas (secret), no GitLab. Abaixo tem-se uma srie de
comandos para listar, renomear, remover e adicionar endereos para remotos.
5.3. FLUXO DE TRABALHO 81
## Lista os remotos.
git remote -v
## Renomeia para um nome melhor

git remote rename origin profs
## Remove.
git remote rm profs
## Adiciona um endereo de remoto (origin)

git remote add origin <url>
git remote add profs <url>
## Adiciona/remove URLs ao origin.

git remote set-url origin --add <url>
git remote set-url origin --delete <url>
Quando voc trabalha em colaborao ou em mais de uma mquina, vai sempre

precisar atualizar os repositrios com o contedo existente no remoto. Existem
duas instrues Git para isso: git fetch e git pull.
As duas tradues mais frequentes do verbo to fetch so buscar e trazer. A
documentao oficial do comando git fetch9 indica que esse comando serve
para trazer objetos e referncias dos repositrios remotos. Abaixo o comando
padro considerando um remoto de nome origin e algumas variaes.
## Traz todos os ramos do remoto origin.

git fetch origin
## Traz s do ramo devel.

git fetch origin devel
## Traz de todos os remotos: origin, profs.

git fetch --all
O comando fetch traz os ramos e atualiza a parte remota, por exemplo, o

origin/devel. O ramo local devel no tem seu contedo modificado aps
o fetch. Para transferir o contedo origin/devel para o devel tem-se que
usar o git merge. No entanto, sempre que haver necessidade, antes do merge
pode-se verificar as diferenas que existem entre local e remoto, principalmente
quando esse remoto traz contribuies de algum colaborador. Os comandos
abaixo exibem as diferenas entre os ramos e aplicam o merge entre eles.
## Muda para o ramo devel.

git checkout devel
## Mostra as diferenas entre devel local e remoto no terminal.
9 https://git-scm.com/docs/git-fetch
git diff devel origin/devel
## Faz o merge do devel remoto no devel local.

git merge origin/devel
Em resumo, para passar o contedo de um ramo remoto para um local temos

que fazer git fetch e em seguida git merge. O comando git pull esses
dois, em um. A documentao do git pull10 d uma descrio detalhada
do seu uso enquanto que os exemplos abaixo ilustram o uso mais simples
possvel.
## Traz e junta todos os ramos do remoto com os locais.

git pull origin
## Traz e junta s do ramo devel.

git pull origin devel
Por fim, para subir o trabalho feito em um ramo, usa-se a instruo git push.
Enviar o seu trabalho com frequncia a melhor forma de ter backups, exibir e
disponibilizar suas contribuies para os seus colaboradores. A documentao
do git push11 rica em variaes mas a maneira mais simples de us-lo para
subir um ramo para o repositrio remoto.
## Sobe o ramo issue#10 para o repositrio remoto origin.

## Sobe todos os ramos.

git push --all origin
Quando voc sobe pela primeira vez um ramo local, a sua parte remota
criada. Assim, a instruo que colocamos acima criou um ramo remoto
chamado origin/issue#10. Essa a forma mais natural, e at despercebida,
de criar ramos locais com cpias remotas, mas existem outras maneiras. Abaixo
fazemos a criao do remoto a partir do local sem ser usando o push. Esses
comandos precisam ser usados uma vez apenas.
## Conectar o local e remoto.

git branch --set-upstream issue#10 origin/issue#10
## Cria o ramo issue#11 a partir e vinculado ao devel remoto.

git checkout -b issue#11 origin/devel
## Cria ramo local issue#12 a partir do remoto com vnculo.

git checkout --track origin/issue#12
## Mostra as ligaes entre pares de ramos: locais e remotos.

git branch -vv
10 https://git-scm.com/docs/git-pull
11 https://git-scm.com/docs/git-push
5.4. MACANSMOS DE COLABORAO 83
5.4 Macansmos de colaborao
Os servios web para Git, mesmo que voc trabalhe sozinho, j so interessan-
tes para ter uma cpia (backup) do seu projeto e disponibilizar seu trabalho.
No entanto, um dos principais objetivos dos servios web permitir a colabo-
rao entre pessoas. J mencionamos o bsico sobre recursos de colaborao
quando falamos de issue, fork e merge request. Nas sesses a seguir, vamos nos
aprofundar nesses trs mecanismos chave para a colaborao via servios web
para Git.
5.4.1 Issues
De acordo com o dicionrio Macmillan12 , issue significa um problema que

precisa ser considerado. Tambm significa um assunto que as pessoas debatem
ou o volume de uma revista. Cabe aqui a primeira definio.
Nos servios web para Git, issue um recurso da interface que permite que as
pessoas abram um assunto/tpico referente ao projeto. Em geral, com os issues
as pessoas externas ao projeto indicam um bug - uma falha a ser corrigida -
ou sugerem que o projeto incorpore determinada caracterstica desejvel. O
dono do projeto avalia a proposta e pode discuti-la logo em seguida, mantendo
as mensagens reunidas e disponveis para outros usurios que acompanham
o projeto. Quando a proposta do issue for implementada, o issue fechado.
Mesmo assim, o issue continua disponvel e pode ser referenciado no futuro,
tanto para novos usurios quanto para incluir no change log do projeto (essa
verso corrige o bug descrito no issue#43, por exemplo).
Quando um projeto coletivo, como so alguns dos projetos no PET Estats-
tica13 , o recurso de issue pode ser usado de outra forma: como gerenciador de
tarefas. Combinado com as milestones, cada membro cria um issue correspon-
dente ao que vai fazer no projeto no perodo de uma semana. Com isso, todos
os demais membros so notificados de que algum j vai trabalhar na tarefa A
do projeto, eliminando foco duplicado. O issue parte do fluxo de trabalho do
PET-Estatstica que ser descrito em outro captulo.
As milestones so uma espcie de coleo de issues que tenham algo em comum.
Considere por exemplo o projeto de um livro. As milestones podem ser os
captulos a serem escritos e os issues podem ser as sees. Se for um projeto de
software, as milestones podem separar os issues referentes ao aperfeioamento
da documentao e ao desenvolvimento do mesmo (escrita de cdigo fonte).
Criar um issue muito simples. Tanto no GitHub quanto no GitLab, existe um
fcil acesso as issues do projeto. Na pgina dos issues voc pode criar um novo
issue, comentar em um j existente e at reabrir um issue que j foi fechado
(comum quando acredita-se ter resolvido um bug mas que ainda no foi). Os
issues so numerados sequencialmente e isso faz com que cada issue seja nico
dentro do projeto. Os servios web at tem formas de fazer hyperlinks para os
12 http://www.macmillandictionary.com
13 https://gitlab.c3sl.ufpr.br/groups/pet-estatistica
issues dentro das mensagens e commits. No GitLab, usa-se um hash seguido do

nmero identificador (e.g. #45) para fazer um hyperlink para um issue.
5.4.2 Fork
A palavra fork, como substantivo, representa forquilha, bifurcao. Esse recurso

est presente nas interfaces web para permitir que usurios faam cpias livres
de projetos de outras pessoas. Como essa cpia do projeto em determinado
instante, h grande chance de divergncia entre cpia e original a partir desse
instante, por isso apropriado a palavra bifurcao.
As finalidades de um fork so duas: 1) ter uma cpia na qual se possa acrescen-
tar modificaes e enviar para o dono as contribuies no projeto original ou
2) usar a cpia como ponto de partida para um outro projeto, sem inteno de
voltar ao projeto original.
No GitHub, o acesso ao fork por um boto que fica mais direita na linha de
ttulo do projeto. No GitLab, o boto de fork fica na pgina inicial do projeto
logo acima do endereo para clonar. Em qualquer um desses servios, uma
vez logado, ao pedir um fork, uma cpia do projeto criada no seu perfil.
Com o fork voc pode colaborar como um terceiro em um projeto, ou seja,
sem ser colaborador adicionado pelo dono. Nessa cpia voc tem permisses
de owner pois na realidade, embora seja uma cpia, ela toda sua. Voc faz
sua cpia livre, trabalha como quiser e no prazo que quiser, e submete ao
projeto original o desenvolvido na sua cpia. O dono do projeto no tem como
saber por que voc fez o fork (mas voc pode criar um issue) nem quando ir
concluir o que almeja. No entanto, quando concluir, para que seu trabalho
seja incorporado ao original, voc ter que fazer um merge request (isso s
possvel entre usurios de um mesmo servio web).
Uma vez com a cpia, voc pode fazer um clone e comear a desenvolver os
projetos. Se a sua inteno submeter modificaes ao original, seja ainda
mais cuidadoso com as mensagens de issue. Escreva sempre no idioma original
do projeto. Muitas vezes, antecipando esse tipo de colaborao, os usurios
disponibilizam guias de contribuio (contribution guide) com instrues de
como proceder para maior agilidade.
Os branchs que criar sero na sua cpia e os pushs que fizer iro para o seu
perfil. Quando o seu trabalho estiver concludo, voc pode fazer um merge
request que descreveremos a seguir. Se a sua inteno foi usar o fork como
ponto de partida para um projeto independente, no se esquea de dar os
devidos crditos ao dono da cpia, mesmo que l no futuro, o seu projeto e o
original sejam completamente diferentes.
5.4.3 Merge Request
O merge request (requisio de mescla/fuso) o recurso de colaborao chave.

Ele serve para que pessoas da equipe (segundos) peam para incorporar
branches ao ramo principal (em geral o master ou o devel) e terceiros peam para
5.4. MACANSMOS DE COLABORAO 85
incorporar o que foi desenvolvido no fork. O GitHub usa o termo pull request
ao invs de merge request embora no exista diferena alguma.
Os trabalhos coletivos em projetos Git, para serem bem sucedidos, consideram
algum esquema de trabalho. A maioria dos esquemas considera o desenvolvi-
mento por branches. Nada mais justo, j que uma uma caracterstica do Git.
Existem ramos permanentes, como o master, que recebem o desenvolvimento
feito em branches auxiliares ou de demanda. Esses ramos de demanda, como o
nome sugere, so criados para incorporar algo ao projeto e, portanto, no so
permanentes - uma vez incorporados, so removidos.
Nos esquemas de trabalho, os membros so instrudos a fazerem o desenvolvi-
mentos nos ramos de demanda e jamais nos ramos permanentes. Ao concluir
essa unidade de trabalho, esse branch enviado para o servidor com um push
## Envia o desenvolvido em um ramo.

Na interface web, o membro faz um merge request desse ramo para um ramo
permanente, no qual em projetos simples o master mas em projetos maiores
usualmente o devel. Ao clicar em merge request, uma caixa de dilogo abre para
que voc liste as colaboraes que o branch leva.
Em ambos os servios, o merge resquest leva para um pgina na qual voc esco-
lhe que ramo de demanda (doador) ser incorporado a um ramo permanente
(receptor). Ao confirmar os ramos envolvidos, tem-se uma caixa de texto desti-
nada as informaes sobre quais as modificaes devem ser incorporadas. Elas
servem para justificar, esclarecer e informar o responsvel pelo merge sobre a
incorporao. Quando o projeto coletivo e no individual, um membro pode
ser indicado como responsvel pelo merge. O responsvel pelo merge avalia
as contribuies, se sentir necessidade v as diffs nos arquivos, e pode colocar
uma mensagem embaixo da sua com questionamentos e at adequaes que
precisarem ser feitas para aceitar o merge request.
Quando trata-se de fork, o processo ocorre de forma semelhante. A sequncia
de etapas : fazer o fork do projeto para a sua conta, 2) clonar o projeto para
sua mquina, 3) criar um branch e fazer o desenvolvimento nele, 4) subir o
branch (push) para a sua conta e 5) fazer um merge request para incorporar
as modificaes. Na hora de escolher o ramo permanente (receptor) tem-se
duas opes: 1) incorporar ao master (ou outro) da sua cpia ou 2) incorporar
ao master (ou outro) do original. Outra opo incorporar ao master da sua
cpia e depois pedir um merge request do seu master para o master do original.
Essa ltima til quando a quantidade de modificaes maior e portanto, o
trabalho vai levar mais tempo.
Os prprios servios web fazem o merge diretamente quando no existe conflito
(merge do tipo fast forward). Isso facilita bastante o trabalho. Porm, no
haver conflito de merge no significa que as modificaes incorporadas esto
funcionais, ou seja, as modificaes feitas precisam ser testadas localmente
para verificar se surtiram efeito. possvel habilitar o servio Git para checar se
o projeto executvel ou funcional. Esse recurso se chama integrao contnua
e veremos na prxima sesso.
Em caso de conflito de merge, tem-se que baixar os ramos (git fetch). Local-
mente pode-se comparar as diferenas entre eles para entender as fontes de
conflito. Para isso so recomendveis as interfaces para Git que sero discutidas
no prximo Captulo. Uma vez que o merge foi resolvido, deve-se fazer o push
do ramo permanente (receptor) para o servio web que j reconhece que o
merge foi feito e fecha a requisio automaticamente.
Recomenda-se que os ramos de demanda sejam removidos aps sua incorpo-
rao nos ramos permanentes. Isso torna o projeto mais claro e concentrado
em ramos definitivos colhedores de desenvolvimento. Pode-se excluir o ramo
de demanda incorporado direto pela interface, marcando uma caixa de confir-
mao sobre remover o ramo aps o merge. Por linha de comando tambm
possvel.
## Deleta o branch issue#33 no servidor (origin).

git push origin :issue#33
## Deleta o branch issue#33 localmente.

git branch -d issue#33
## Deleta a cpia do issue#33 que veio do origin.

git branch -dr origin/issue#33
Ao incorporar uma contribuio grande, interessante marcar o commit vin-

culado esse merge de uma forma destacvel, como por exemplo, com uma
tag.
## Lista as tags existentes.

git tag
## Adiciona uma tag anotada ao ltimo commit.

git tag -a v1.0 -m "Verso 1.0 do software"
5.5 Integrao contnua

Quando voc est trabalhando em um projeto Git, cada commit, cada branch,
contm algum desenvolvimento. Solucionar conflitos de merge no uma
tarefa complicada, principalmente se forem consideradas as ferramentas certas
para isso, como ser visto no prximo captulo. No entanto, para cada commit
tem-se a preocupao: ser que o projeto est funcional?
Reprodutibilidade uma questo de fundamental importncia em projetos cole-
tivos ou pblicos. Existe a preocupao constante de que seu cdigo (programa)
seja executado (instalado) sem erros nos ambientes dos seus colaboradores ou
usurios. claro que o desenvolvimento do projeto visa aperfeio-lo mas o
tempo todo estamos sujeitos a fazer modificaes que induzem erros e algum
encontra erros no esperados (bugs).
Monitorar erros no projeto em desenvolvimento no uma tarefa fcil, princi-
palmente em trabalhos coletivos nos quais cada colaborador tem um ambiente
5.5. INTEGRAO CONTNUA 87
de trabalho. Em uma situao ideal, algum teria que testar se o projeto corre
sem erros (cdigo executa, software instala) em uma mquina cliente (com
os requisitos mnimos exigidos), toda vez que um commit fosse feito, j que o
commit indica que modificaes foram feitas. Ento, se correu sem erros, avisar
todos que podem prosseguir, mas se falhou, informar a equipe, encontrar e
corrigir a falha.
No raro algo ser bem sucedido no ambiente em que foi desenvolvido e
apresentar falhas no ambiente de outra pessoa. O melhor jeito de antecipar
erros testar em um ambiente virgem, uma mquina cliente que contenha
apenas os requisitos mnimos necessrios ao projeto.
A Integrao Contnua (IC) a soluo desse problema. A ideia manter
o repositrio Git continuamente integrado um ambiente cliente que faz
verificaes no projeto a cada novo push.
Fazer integrao contnua no GitHub e GitLab, embora o conceito seja o mesmo,
tem algumas diferenas. Paro o GitHub existem diversos servios de IC, sendo
eles terceirizados. J o GitLab CE tm o servio prprio de IC a partir da
verso 8.0. Apresentaremos cada um deles na sesso seguinte.
Independe do servio web, as principais vantagens da IC14 so:
1) Economia de tempo com superviso de cdigo e procura de falhas. Com

a verificao mais frequente, a cada commit/push, menos tempo gasto
na correo de bug, que devem ser tambm menores, assim deixando
mais tempo para desenvolver o que interessa.
2) Verificao em um ambiente virgem sem efeito de variveis de ambiente
locais.
3) Verificao em vrios ambientes (sistemas operacionais, arquiteturas,
dependncias e verses);
4) Informao coletiva e imediata equipe da causa de falha na hora
que ela ocorre, o que aumenta a visibilidade, facilita a comunicao e
direcionamento de esforos.
5) Indicao de sucesso ou no na home do projeto e nos branches disponvel
antes do merge;
6) Entrega de verses estveis, documentao e arquivos acessrios com
continuous deployment, o que facilita o empacotamento e disponibilizao
do projeto.
7) Custo computacional reduzido j que feito em um servidor dedicado.
8) Acaba saindo mais barato do que parar o projeto para corrigir um erro.
O que deve ficar claro que a integrao contnua no elimina erros, mas faz
com que eles sejam mais fceis de identificar e corrigir.
Sem a automao, os espaos entre verificaes podem ficar longos. Encontrar
um bug em tantos commits mais difcil, encontrar no cdigo mais ainda.
Pode atrasar a entrega do projeto e comprometer a receita e popularidade.
Integraes peridicas so mais fceis e leves.
O fluxo de trabalho de um repositrio com IC basicamente assim:
14 https://about.gitlab.com/gitlab-ci/
1) Os desenvolvedores trabalham no projeto em seu workspace pri-

vado/local;
2) Periodicamente fazem commits e pushs para o repositrio remoto;
3) O servio de IC monitora o repositrio toda vez que modificaes ocor-
rem;
4) O servio de IC corre todos os testes de inspeo que foram configurados
(instala dependncias, executa scripts, cria/transfere arquivos, etc);
5) O servio de IC disponibiliza produtos da verificao, como binrios de
instalao e documentao (no caso de sucesso) ou log de execuo (no
caso de falha);
6) O servio de IC assinala no repositrio Git o status da verificao: su-
cesso/fracasso;
7) O servio de IC informa a equipe dos resultados por mensagem de e-mail
ou web hooks, como o Slack;
8) A equipe toma das providncias cabveis na primeira oportunidade, como
corrigir a falha ou anunciar o sucesso;
9) O servio aguarda por mais modificaes;
5.5.1 GitHub
Embora exista uma lista grande de servios de integrao contnua disponveis

para repositrios GitHub, um dos mais usados o Travis CI15 . Travis CI
(continuous integration) um servio free e open source destinado integrao
contnua para projetos pblicos no GitHub.
Para vincular um projeto no GitHub com IC no Travis CI, voc precisa logar
no https://travis-ci.org/ com a sua conta do GitHub. Assim que voc logar,
d autorizao para acessar seus repositrios e em uma lista voc deve marcar
os que usaro o servio. A prxima etapa criar um arquivo .travis.yml na
raiz do seu repositrio Git. Esse arquivo oculto especifica todas as instrues
que devem ser feitas a fim de verificar seu repositrio. Se seu repositrio um
pacote R, por exemplo, esse arquivo vai ter instrues de instalao do pacote.
Cada projeto, cada linguagem, tm uma forma particular de ser testada.
Para pacotes R, o Travis CI tem uma documentao de orientao: https:
//docs.travis-ci.com/user/languages/r/. Alm disso, uma boa prtica em ver
exemplos em uso, como o .travis.yml dos pacotes R knitr16 e devtools17
que esto na lista dos mais utilizados.
Para todas as linguagens e objetivos tm-se exemplos de arquivos
.trevis.yml. Para o Emacs e bibliotecas lisp visite https://github.com/
rolandwalker/emacs-travis, https://github.com/Malabarba/elisp-bug-hunter
e https://github.com/abo-abo/tiny. Para projetos em C++ e phyton, as-
sim como o R, o Travis CI tem uma documentao introdutria. Visite
https://docs.travis-ci.com/user/language-specific/ para ver a lista de
documentaes.
15 https://travis-ci.org/
16 https://github.com/yihui/knitr
17 https://github.com/hadley/devtools
Alm do linguagens de programao, possvel testar inclusive a

compilao de um documento Latex: http://harshjv.github.io/blog/
setup-latex-pdf-build-using-travis-ci/.
5.5.2 GitLab
A Integrao Contnua passou fazer parte do GitLab CE na verso 8.018 , lanada

em setembro de 2015. Diferente do GitHub, essa verso do GitLab tem o IC de
forma nativa. Voc pode configurar servidores externos para executarem as
verificaes ou pode faz-las no mesmo servidor que roda o GitLab.
Alan Monger19 descreve como configurar um servidor Ubuntu no Digital
Ocean20 parar verificar repositrios hospedados no https://gitlab.com/.
Segundo ele, o primeiro passo acessar https://gitlab.com/ci/ para adicionar
o projeto integrao contnua. Na sua matria, Alan descreve como instalar
um Virtual Private Server com Ubuntu 14.04 no Digital Ocean. Em seguida
instala o runner (gitlab-ci-multi-runner) o configura e habilita. Por fim, o
arquivo .gitlab-ci.yml, que especifica o que deve ser executado, criado na
home do repositrio.
O GitLab do LEG21 tem o CI embutido pois a verso mais recente do
servio. Essa servidora na realidade um desktop com Ubuntu Server 14.04.
patrimnio da UFPR de responsabilidade do LEG mas tem uso compartilhado
com o PET Estatstica e colaboradores do Laboratrio. Desde a disponibilizao
do GitLab, em julho de 2015, mantemos artigos, materiais de ensino (aulas,
provas, scripts), tutoriais e matrias de blog em devolvimento colaborativo,
alm de pacotes R.
Nessa servidora, criamos um usurio chamado gitlab-runner com o qual
fazemos as integraes contnuas. Toda vez que um projeto com o arquivo
.gitlab-ci.yml recebe um push, as instrues nesse arquivo executam a IC
com o usurio gitlab-runner. Tecnicamente podemos correr todo tipo de
comando ou programa disponvel no servidor em questo. At ento, os
repositrios com IC so s dois: legTools22 e mcglm23 , dois pacotes R.
5.5.2.1 O arquivo de configurao .gitlab-ci.yml
A documentao oficial sobre como usar o arquivo .gitlab-ci.yml encontra-se

em http://doc.gitlab.com/ce/ci/yaml/README.html.
O arquivo .gitlab-ci.yml fica na raiz do projeto. Seu contedo define todo o
processo de verificao do seu repositrio a partir de uma srie de instrues,
como execuo de comandos diretos ou execuo de scripts. Abaixo tem-se
um exemplo simples de .gitlab-ci.yml.
18 https://about.gitlab.com/2015/09/22/gitlab-8-0-released/
19 http://alanmonger.co.uk/php/continuous/integration/gitlab/ci/docker/2015/08/13/
continuous-integration-with-gitlab-ci.html
20 https://www.digitalocean.com/
21 http://git.leg.ufpr.br/
22 http://git.leg.ufpr.br/leg/legTools
23 http://git.leg.ufpr.br/wbonat/mcglm
job1:
script: "teste_instalacao.sh"
job2:
script:
- pwd
- ls -a
Neste exemplo existem dois jobs (tarefas). Cada um deles corre independente e
podem ser executados simultaneamente. O primeiro executa um script shell e
o segundo comandos shell em uma lista. Porm, tais arquivos podem ser bem
mais complexos, com campos alm do script:. Os campos a seguir so todos
opcionais:
image: para especificar uma imagem docker24 . O tutorial de Alan Monger

considera esse campo.
services: tambm refere ao docker. Tais campos so de uso menos

frequente, porm existe uma srie de vantagens neles. A documentao
oficial sobre isso encontra-se em http://doc.gitlab.com/ce/ci/docker/
README.html.
before_script: define comandos/scripts a serem executados antes dos

comandos verificadores. So normalmente instrues de preparao das
quais no se espera falhas pois no devem depender do projeto.
stages: define a ordem de excecuo dos jobs para uma cadeia de exe-
cuo condicional. Jobs de mesma ordem ou do mesmo estgio so
executados paralelamente mas queles frente s so executados se
houver sucesso dos predecessores.
stages:
- construcao
- teste
- entrega
job_contrucao:
script: "construcao.sh"
stage: construcao
job_test:
script: "teste_codigofonte.sh"
script: "teste_documentacao.sh"
stage: teste
job_entrega:
script: "compacta_transfere.sh"
stage: entrega
24 https://www.docker.com/
variables: serve para criar variveis de ambiente que podem ser usados
por todos os comandos e scripts. Tais variveis podem armazenadas se-
nhas de acesso, necessrias por exemplo para instalao de componentes
e acesso bancos de dados.
cache: indica os diretrios e arquivos que sero mantidos entre os jobs

(builds), possivelmente porque so aproveitados futuramente.
Com exceo dos nomes listados acima, um job pode ter qualquer nome, desde
que seja exclusivo. Dentro de um job tem-se tambm uma lista de campos
disponveis para configur-lo:
script: especifica script shell ou uma lista de comandos a serem executa-

dos.
stage: j mencionado anteriormente, serve para dar a ordem de execuo

dos jobs. Vrios jobs podem ser do mesmo estgio e nesse caso so
executados paralelamente.
only e except: servem para restringir a execuo do job, incluindo ou

excluindo, para uma lista de referncias Git, como branches ou tags. Esse
campo permite expresses regulares, teis para incluir (excluir) ramos
representveis por regex, como so os ramos de desenvolvimento do
nosso workflow, iniciados com issue.
job_test:
script: "teste_codigofonte.sh"
script: "teste_documentacao.sh"
stage: teste
only:
- /îssue.*$/ ## Filtra os que comeam com issue.
tags: so usadas para indicar o runner da lista de disponveis. Na

configurao dos runners pode-se atribuir tags que servem justamente
para esse tipo de pareamento.
allow_failure: indica jobs que, mesmo que falhem, no sero considera-

dos para dar estampa de sucesso ou falha, ou seja, um teste mas no
crucial.
when: um comando que dispara excusses condicionais ao sucesso do

job anterior
on_failure: so instrues executadas quando algum job do estgio

anterior falhou.
on_success: so instrues executadas quando todos os jobs do
estgio anterior foram bem sucedidos.
always: executados sempre.
cache: especifica arquivos e diretrios mantidos entre um job e outro.

No caso do pacote legTools, o arquivo .gitlab-ci.yml do repositrio tem o

seguinte contedo:
job_R:
script:
- echo $HOME
- Rscript -e 'getwd(); .libPaths(); sessionInfo()'
- Rscript -e 'library(devtools); check()'
- Rscript -e 'library(devtools);\
.libPaths(path.expand("~/R-tests/legTools"));\
install(local = FALSE)'
Estas so instrues em shell que chamam o R com expresses passadas para

Rscript -e para fazer a instalao do pacote. Na ocorrncia da primeira falha,
o processo logicamente interrompido e os colaboradores podem ver a causa
em http://git.leg.ufpr.br/leg/legTools/builds. No caso do build correr sem
falhas, tem-se uma estampa de success. Essa estampa tambm vai aparecer no
README.md na pgina de rosto do projeto, basta para isso colocar o seguinte
contedo no arquivo.
![](http://git.leg.ufpr.br/ci/projects/1/status.png?ref=master)
Caso queira a estampa para outros ramos, s acrescent-los.
5.5.2.2 Runners
Em poucas palavras, um runner uma mquina que executa o build por meio
do GitLab CI. Um runner pode ser especfico de um projeto ou pode ser um
runner compartilhado, disponvel todos os projetos. Estes ltimos so teis
projetos que tem necessidades similares, como todos queles projetos que
so pacotes R, por exemplo. Isso facilita a administrao e atualizao. Os
especficos, por outro lado, atendem projetos com demandas particulares.
Apenas usurios com permisses de admin podem criar runners compartilha-
dos.
Em Settings Services marque o campo active. Isso vai criar 6 novas entradas no
menu da esquerda:
Runners: contm instrues de como usar os runners especficos e com-

partilhados.
Variables: define variveis que so omitidas no log do build, til para
passar senhas.
Triggers: servem para TODO
CI Web Hooks: esse web hook pode ser usado para criar eventos quando o
build concludo.
CI Settings: configuraes gerais.
CI Services: permite integrar o CI com outros servios, como e-mail e
Slack.
Para habilitar um runner, necessrio instalar o gitlab-ci-multi-runner. O

repositrio oficial do GitLab Runner25 contm as instrues de instalao e
configurao e a documentao oficial runners26 indicando como tirar melhor
proveito do recurso.
25 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner
26 http://doc.gitlab.com/ce/ci/runners/README.html
Captulo 6
Ferramentas grficas
No Git, todo o gerenciamento do projeto realizado via CLI (Command line

interface), linhas de comando interpretadas, geralmente pelo bash. Isso confere
um maior controle e segurana nas aes realizadas, mas em muitas situaes
os comandos e outputs Git no se apresentam de forma to amigvel, seja pela
difcil memorizao ou pela interatividade limitada.
Os comandos mais usuais como git adde git commit se tornam simples,
pois mesmo para um usurio iniciante eles fazem parte do cotidiano em um
projeto sob versionamento Git. Porm, algumas situaes no ocorrem com
frequncia, como por exemplo voltar a verso de um arquivo ou do repositrio
requerem comandos que so pouco utilizados e para realiz-las necessrio a
consulta de algum material. Outra situao em que a utilizao dos comandos
dificultada, ocorre em projetos grandes, uma vez que muitos arquivos so
alterados simultaneamente. Neste caso o procedimento de commit se torna
trabalhoso, pois necessrio listar todos os arquivos que fazem parte de um
commit no commando git add. Uma ltima situao exemplo em que o uso de
CLI no parece satisfatrio na comparao de arquivos, j usamos o comando
git diff no captulo 3 e o output deste comando foi de simples visualizao,
mas em arquivos grandes (com muitas linhas) a navegao para verificar as
alteraes do arquivo no to amigvel. Para facilitar essas e outras situaes
surgem as GUIs (Graphical User Interfaces), interfaces grficas para o usurio
incorporar comandos Git em widgets(botes, caixas de texto etc.) dispostos em
uma janela grfica de seu sistema operacional.
Neste captulo apresentamos as principais GUIs para projetos Git em diferentes

plataformas, sistemas UNIX, Mac OS X e Windows. Seccionamos em dois
conjuntos de interfaces. O primeiro chamado de Interfaces Git refere-se s
ferramentas para alteraes e visualizaes de arquivos no repositrio a fim
de facilitar as atividades cotidianas. J o segundo, Interfaces de comparao,
representam as que objetivam facilitar a visualizao e edio de arquivos com
base em suas diferentes verses. Detalhes de download, instalao e exemplos
da utilizao destas interfaces no fluxo de trabalho de um projeto so descritos.
95
96 CAPTULO 6. FERRAMENTAS GRFICAS
6.1 Interfaces Git

Neste material chamaremos de Interfaces GIT as GUIs para gesto de um
repositrio. Estas facilitam a utilizao das principais instrues Git (git add,
git commit, git push, git pull), visualizao dos arquivos e alteraes no
repositrio.
6.1.1 git-gui
Baseada em Tcl/Tk, a GUI chamada git gui man-

tida como projeto independente do Git, mas as ver-
ses estveis so distribudas junto com o programa
principal, portanto no necessrio o download e ins-
talao. A interface voltada para realizar alteraes
no repositrio, desde as mais simples como commitar
arquivos at as mais especficas como voltar estgios
ou reescrever o ltimo commit (muito til quando
notamos erros de gramtica logo aps a submisso).
Nesta seo abordaremos apenas as alteraes mais
comuns no repositrio.
A git gui no Windows, pode ser aberta pelo menu
iniciar. Nesta plataforma, ao instalar o Git (conforme Figura 6.1: Logo usada
visto no captulo 2), optamos pelos componentes para a git-gui, tam-
git BASH e git GUI. Assim estas aplicaes ficam bm uma das logos
disponveis para uso. Em sistemas UNIX, a interface do prprio GIT
pode ser instalada via terminal, tambm apresentada
no captulo 2:
## Instalando a git gui

sudo apt-get install git-gui
Ainda em sistemas Unix podemos criar um alias (criar ou editar adequadamente

um arquivo em /usr/share/applications) para que a git gui fique listada junto
s aplicaes do sistema. Porm, de forma geral, independente da plataforma
de trabalho, a git gui pode ser iniciada a partir de um terminal bash, com o
comando:
git gui
Para exemplificar a utilizao desta interface vamos alterar alguns arquivos do

repositrio meu1repo criado no captulo 3.
## Destaca ttulo no README

sed -i "2i\--------------------" README.txt
sed -i "1i\--------------------" README.txt
## Destaca ttulo no porqueLinux

6.1. INTERFACES GIT 97
sed -i "2i\--------------------" porqueLinux.txt

sed -i "1i\--------------------" porqueLinux.txt
## Corrige nome do autor citado

sed -i "s/Lunus/Linus/g" README.txt
## Cria um novo arquivo TODO.txt

echo "
Lista de afazeres:
--------------------
* tarefa 1
* tarefa 2
* tarefa 3" > TODO.txt
Agora visualizando o estado do repositrio aps nossas modificaes, ainda

via terminal:
git status
On branch master
Untracked files:
TODO.txt
A partir daqui poderamos seguir o fluxo de gesto de verses via terminal,

apresentado no captulo 3. Mas faremos isso agora via interface git gui.
A interface git gui se apresenta de forma simples, o que facilita sua utilizao.
Na figura 6.2 destacamos as quatro reas que compreendem a interface. Na
primeira poro temos listados os arquivos presentes no working directory, os
arquivos criados aparecem com cone em branco e os modificados com linhas
em azul, aqui a interface implementa interativamente o comando git add,
pois ao clicar no cone de um arquivo ele automaticamente adicionado a
staging area. Na segunda parte so listados os arquivos na staging area com
cone de check mark. Na terceira parte temos a implementao do comando git
diff para qualquer arquivo selecionado. Com destaque de cores, a interface
apresenta em vermelho as delees e em verde as adies. Por fim temos no
canto inferior direito a rea para escrever commits com botes para submisso
Figura 6.2: Screenshot da execuo do programa git-gui
de ao. Um detalhe importante do git gui que o idioma do sistema opera-

cional verificado para sua construo, ou seja, os botes da interface na figura
6.2 so push, commit, sign off, etc, pois o idioma do sistema operacional em
que essa interface foi executada o ingls. Para outros idiomas as mensagens
podem sofrer alteraes.
Alm das quatro reas principais da interface, que facilitam interativamente ati-
vidades como git status, git diff, git add, git commit e git push, temos
mais implementaes no menu da interface para procedimentos no cotidia-
nos. Essas implementaes podem ser acessadas com um simples clique e so
auto-explicativas.
6.1.2 gitk
Pioneira dentre as interfaces grficas, gitk foi a pri-

meira GUI implementada. Tambm escrita em Tcl/Tk,
esta GUI tem como objetivo a apresentao do hist-
rico de um projeto. A gitk incorporada ao principal
repositrio do Git, portanto nas instalaes comple-
tas, esta interface fica disponvel sem ser necessrio
download e instalao. Nesta seo apresentamos a
gitk, detalhando a disposio dos elementos nesta
interface que se mostra muito til na visualizao de Figura 6.3: Logo da in-
projetos. terface gitk, smbolos
de supresso e adio
so caractersticos das
logos GIT
Figura 6.4: Screenshot da execuo do programa gitk
A gitk trabalha em conjunto com a git gui. Em git

gui podemos fazer alteraes de forma rpida e vi-
sual nos arquivos que esto na staging area e working
directory, porm para visualizar o histrico completo
de commits com ramificaes, marcaes e demais detalhes, recorremos gitk,
uma prova disso que no menu da git gui temos um atalho para a gitk
Repository Visualize History . Essa interface se mostra muito til tambm como
ferramenta de aprendizagem Git, uma vez que visualizar de forma grfica as
alteraes que os comandos realizados causam no projeto, torna mais fcil a
compreenso dos mesmos.
gitk, assim como a git gui pode ser chamada atravs da linha de comando:
gitk
Para exemplificar a disposio dos elementos nesta interface, seguimos com as

alteraes feitas na seo anterior, lembrando que temos todas as alteraes
j realizadas no captulo 3 e ainda duas modificaes e uma incluso de
arquivo no commitados. Visualizando a interface gitk chamada neste estado
do repositrio temos:
Perceba na figura 6.4 que esta interface mais completa do que a git gui
no que diz respeito informao. Dividida em apenas duas partes, a gitk
apresenta na primeira todo o histrico do projeto, contempla uma implementa-
o visual e agradvel do comando git log --graph. No grfico apresentado
na parte superior, as bolinhas em azul representam commits passados, a de

amarelo indica o estado atual do repositrio e em vermelho so as modifica-
es no working directory. Ao lado esto os autores dos respectivos commits e
o momento em que foram feitos. Na parte inferior da interface temos o deta-
lhamento do commit selecionado na parte superior. As informaes contidas
aqui vo desde identificador do commit (SHA1 ID), diferena das modificaes
referenciadas com relao ao estado anterior do repositrio at a listagem dos
arquivos atingidos pelo commit selecionado.
Alm da excelente apresentao visual do repositrio Git, a interface gitk
tambm permite algumas alteraes. Clicando com o boto direito de seu
mouse em qualquer commit listado, podemos criar tags, reverter o repositrio
neste estado, criar um ramo a partir do commit dentre outras opes possveis
atravs da interface.
6.1.3 Outras Interfaces
6.1.3.1 gitg e gitx
Estas duas interfaces tentam juntar em uma nica as opes proporcionadas

pela git gui e pela gitk. Os layouts e as propostas so similares, a diferena
est na portabilidade. A gitg implementada em GTk+ e est disponvel
para sistemas UNIX e a gitx foi implementada para Mac OS seguindo o estilo
de aplicativos deste sistema operacional. De forma geral no h detalhes a
serem repassados sobre estas interfaces uma vez que as possibilidades j foram
listadas nas sees sobre git gui e gitk
6.1.3.2 RabbitVCS
RabbitVCS uma coleo de ferramentas grficas para navegadores de arquivos

do sistema LINUX que permitem o acesso simples e direto aos sistemas de
controle de verso Git e/ou Subversion. No se caracteriza como interface,
porm altera a visualizao no navegador de arquivos de diretrios sob versio-
namento, alm de dispor de aes implementadas nas opes do menu quando
pressionado o boto direito do mouse.
Figura 6.5: Screenshot da execuo do programa gitg

Figura 6.6: Screenshot do programa gitx

6.1. INTERFACES GIT
103
Figura 6.7: Screenshot do Navegador Nautilus com uso do RabbitVCS
Na figura 6.7 temos o screenshot do repositrio meu1repo no navegador de

arquivos nautilus (padro do sistema Ubuntu 14.04). Perceba que com essa
interface os cones de arquivos e pastas no navegador ganham destaque com
um outro pequeno cone na parte inferior. Estes pequenos cones indicam o
estado do arquivo sem precisar recorrer ao terminal, ou seja, temos um git
status no prprio navegador de arquivos. Alm disso RabbitVCS complementa
o menu de opes acessados com o boto direito do mouse. Essas opes so
completas, vo desde commits, criao de branchs e tags, reverter o estado do
repositrio, at atualizar com a verso remota, entre outras.
6.1.3.3 git-cola
Esta tambm uma interface alternativa que se destaca por ser completa e
portvel (disponvel para sistema LINUX, Windows e Mac). Implementada
em python, a git-cola uma alternativa git gui e contm praticamente os
mesmos elementos para alteraes no repositrio. Como a git gui se auxilia
da gitk para visualizao, a git-cola tambm tem uma interface de apoio,
chamada de git-dag que vem instalado junto ao git-cola.
Perceba pela figura 6.8 que as opes das interfaces so similares as apresen-
tadas em git gui e gitk. As interfaces git-cola e git-dag se destacam pela
fcil manipulao do layout exibido, alm de deixar a interface mais intuitiva
possvel. Como destaque em implementao de funcionalidade Git, a git-cola
se sobressai com relao git gui na possibilidade de execuo do comando
git rebase via interface.
6.1.3.4 Plugins e extenses para editores
Muitas vezes inconveniente trabalhar com cdigos fonte em um editor e

ter que abrir um terminal bash em outra janela do sistema operacional para
verificar o sistema de versionamento, realizar commits, etc. Felizmente alguns
editores possuem um sistema Git integrado, seja por meio de plugins adicionais
instalados ou pela opo nativa do editor.
Destacamos aqui dois editores, comumente utilizados pela comunidade esta-
tstica, que possuem os comandos Git integrados sua interface. So eles, o
emacs, o qual temos as opes de buffers no editor onde podemos abrir uma
instncia shell e executar os comandos Git junto com o desenvolvimento do c-
digo fonte. Alm disso uma extenso poderosa chamada magit1 est disponvel
e em desenvolvimento para o uso no emacs, esta extenso proporciona opes
de comandos e visualizao em um buffer do editor que facilita o trabalho de
versionamento. Outro editor tambm muito utilizado em Estatstica, talvez o
mais utilizado pela comunidade, o RStudio que tambm implementa em sua
interface vrios comandos, assim como as interfaces anteriormente descritas
e tarefas no triviais, uma chamada do terminal Shell possvel dentro do
aplicativo. Devido ao seu grande uso, o RStudio ter uma seo especfica
onde as diversas ferramentas sero exploradas, com exemplos e ilustraes
voltadas para a comunidade estatstica.
1 Informaes em http://magit.vc/
Figura 6.8: Screenshot dos programas git-cola e git-dag

6.2 Interfaces de comparao
Uma das principais vantagens do Git a possibilidade de trabalho paralelo

por dois ou mais usurios ou por ramos de desenvolvimento. E como qual-
quer desenvolvimento paralelo, desejamos ao final do trabalho, mesclar as
contribuies realizadas lado a lado. Como vimos no captulo 3 isso feito
atravs do comando git merge ramo_desenvolvimento para ramos locais e
git push origin quando estamos trabalhando em equipe e as contribuies
so enviadas para um servidor remoto, captulo 4. Porm, quando a mesma
poro de um mesmo arquivo alterada em duas instncias distintas (ramos
diferentes, usurios diferentes etc.) ocorrem conflitos e vimos como o Git
os sinaliza para que possamos resolv-los. Nesta seo mostraremos como
as interfaces grficas dedicadas resoluo de conflitos na mesclagem e
visualizao da diferena de arquivos em estados diferentes do repositrio
podem nos auxiliar.
H vrios programas que objetiva a comparao visu-
almente agradvel de arquivos. Aqui iremos abordar
o programa meld, que multiplataforma open source
e tem vrias facilidades implementadas, porm ou-
tras alternativas sero indicadas, e devido equidade
de objetivos todos os comentrios feitos para o meld
podem ser adotadas para os demais.
O programa meld implementado em python e se
denomina como uma ferramenta de diferencia- Figura 6.9: Logo do
o e mesclagem voltada para desenvolvedores, aplicativo meld, no h
o programa pode ser baixado para as plataformas descries sobre o seu
UNIX, Mac OS X e Windows atrves do endereo significado, mas nos pa-
http://meldmerge.org/. O meld no uma ferra- rece representar mis-
menta especfica para o Git, como as apresentadas tura, como mistura de
na seo 6.1, porm permitido e ser usado para arquivos
comparar verses de arquivos ou repositrios, mas
vamos comear apresentando o meld como programa
independente.
Inicializando o programa, sua tela inicial dever ser similar a apresentada na
figura 6.10, aqui estamos utilizando um sistema operacional Ubuntu 14.04. A
partir da podemos escolher quaisquer dois (ou trs) arquivos ou diretrios
para comparao.
A partir da escolha, o meld apresenta os arquivos ou diretrios lado a lado para
comparao e destaca as pores dentro dos arquivos que esto discordantes.
A figura 6.11 apresenta a comparao de dois arquivos, que salvamos como
README_v1 e README_v2 (relembrando os velhos tempos antes de conhecermos
o Git).
Com isso j podemos notar onde utilizar esta ferramenta no fluxo de traba-
lho de um projeto sob versionamento. Vamos ento voltar ao nosso projeto
meu1repo, iniciado no captulo 3 e alterado na seo 6.1 (Interfaces Git). As
alteraes realizadas no foram salvas, ento podemos visualiz-las no meld. A
inicializao do programa pode ser feita via linha de comando git difftool,
6.2. INTERFACES DE COMPARAO 107
Figura 6.10: Screenshot do tela inicial do programa meld RabbitVCS
Figura 6.11: Screenshot de comparao de arquivos com programa meld

RabbitVCS
s temos que informar o programa a ser utilizado com a opo -t (abreviao

de --tool). Nos sistemas UNIX, o programa pode ser lanado apenas atravs
do nome meld.
## Compara o arquivo README (UNIX)

git difftool -t meld README.md
Para utilizao em sistemas Windows, programas externos ao Git devem ser

informados no arquivo de configurao (.gitconfig). Abaixo configuramos,
via linha de comando, este arquivo para usarmos o meld como ferramenta de
comparao - difftool, tanto para usurios Unix como usurios Windows:
## Define localmente o meld como ferramenta padro de diff

##-------------------------------------------
## Unix.
git config diff.tool meld
##-------------------------------------------
### Windows.
git config diff.tool meld
git config difftool.meld.cmd '"path/Meld.exe" $LOCAL $REMOTE'
onde path o caminho para o arquivo executvel do programa meld. $LOCAL

representa o arquivo na sua verso local e $REMOTE na sua verso remota. Assim
o programa pode ser lanado apenas com o comando:
## Compara o arquivo README (WINDOWS)

git difftool README.md
Na figura 6.12 temos o screenshot do programa aps executado o difftool.

Nesta figura temos a mesma informao trazida pelas interfaces onde im-
plementam o comando git diff, porm aqui podemos alterar os arquivos
exibidos atravs das flechas nas bordas (levando ou trazendo as contribuies)
ou mesmo editando pela interface. Isso pode ser til caso necessite desfazer
parcialmente um commit, ou seja, parte das alteraes de uma verso anterior
seria mantida e parte alterada.
Contudo, a maior necessidade das ferramentas de comparao no est no
seu uso como difftools, mas sim como mergetools. J vimos no captulo 3
que h momentos em que a mesclagem de ramos gera conflitos e estes eram
resolvidos abrindo e editando os arquivos conflitantes. Porm com o meld ou
outras interfaces de comparao, podemos realizar a resoluo de conflitos via
interface.
Para exemplificar a utilidade na resoluo de conflitos na mesclagem, vamos
marcar as alteraes j feitas no meu1repo e criar um novo branch alterando os
mesmos arquivos a fim de gerar conflito.
Figura 6.12: Screenshot do programa meld utilizado como difftool para o

arquivo README.txt RabbitVCS
## Criando um novo ramo para desenvolvimento

git branch feature05
## Registrando as alteraes no ramo master

git add .
git commit -m "Adiciona TODO e corrige README"
## Indo para o ramo feature05

##-------------------------------------------
## Alterando README para induzir conflito
## Destaca ttulo no README

sed -i "2i\####################" README.txt
sed -i "1i\####################" README.txt
## Corrige citaes, de "'" para """

sed -i "s/'/\"/g" README.txt
##-------------------------------------------
## Registrando as alteraes no ramo feature05

git add .
git commit -m "Adiciona lista de coisas a se fazer"
[master 7e9c4ab] Adiciona TODO e corrige README

3 files changed, 11 insertions(+), 1 deletion(-)
create mode 100644 TODO.txt
[feature05 dfe7bba] Adiciona lista de coisas a se fazer
1 file changed, 4 insertions(+), 2 deletions(-)
Tentando incorporar as contribuies realizadas acima, do ramo changes para

o ramo master obtemos:
## Retorna ao ramo principal

git checkout master
## Tentativa de mesclagem
git merge feature05
Auto-merging README.txt
CONFLICT (content): Merge conflict in README.txt
Automatic merge failed; fix conflicts and then commit the result.
E agora, ao invs de editarmos o arquivo em conflito, vamos utilizar a ferra-

menta meld para resolver os conflitos. Para isso, execute o seguinte comando
no terminal:
## Lanando a interface `meld` para resoluo de conflitos

git mergetool -t meld
6.2. INTERFACES DE COMPARAO
Figura 6.13: Screenshot do programa meld utilizado como difftool para o arquivo README.txt RabbitVCS
111
Na figura 6.13 temos a janela do programa meld quando usado para resoluo
de conflito, conforme comando descrito anteriormente. So apresentados trs
verses lado a lado de cada arquivo em conflito: direita temos a verso LOCAL,
com o estado do arquivo no ramo atual; esquerda o REMOTE, que representa
a verso com as alteraes a serem mescladas e; finalmente na poro central
temos o BASE, com o contedo de uma verso anterior comum a ambos. Assim
como apresentado na figura 6.12, em que o meld foi utilizado como difftool,
podemos (e neste caso devemos) editar um arquivo o BASE, exibido na poro
central do aplicativo. Este arquivo ser o definitivo ao fim da mesclagem, nele
podemos incluir as contribuies apresentadas no que batizamos de LOCAL e
REMOTE. Isso facilita a resoluo de conflitos, pois podemos ver as contribuies
lado a lado e decidir como dever ficar o arquivo definitivo.
Aps a edio do arquivo, o processo de mesclagem pode continuar normal-
mente. Abaixo conclumos o processo via linha de comando:
## Verificando o estado do repositrio

git status
On branch master
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Untracked files:
README.txt.orig
## Conclui a mesclagem com a mensagem de commit curta

git commit -m "Resolve conflito via meld"
[master 112a71b] Resolve conflito via meld
Para resoluo de conflitos via alguma ferramenta grfica com o comando

git mergetool, o Git gera arquivos de backup com extenso .orig. Perceba
no output gerado pelo git status que estes armazenam o contedo de cada
arquivo em conflito com as pores conflitantes. recomendvel no versionar
estes arquivos de backup. Podemos ento simplesmente exclu-los ou ignor-los
aps a mesclagem adicionando arquivos com esta extenso no .gitignore.
Outra forma de manter seu repositrio sem os arquivos backup configurando
sua mergetool para no armazen-los, ou seja, que a prpria ferramenta os
descarte quando a mesclagem for bem sucedida. Isso pode ser configurado
com:
## Configura a ferramenta de merge para no criar os backups

git config --global mergetool.keepBackup false
O procedimento de conflito simulado acima foi resolvido utilizando o programa

meld, com os comandos definidos para os sistemas baseados no kernel LINUX.
Ainda a chamada do programa foi realizada atravs da opo -t (ou --tool).
Porm podemos definir o meld como ferramenta padro para resoluo de
merge, assim como foi feito para a ferramenta de comparao (difftool).
Abaixo configuramos o meld tambm como mergetool, para sistemas Unix e
Windows.
## Configura localmente meld como ferramenta padro de merge

##-------------------------------------------
## Unix
git config merge.tool meld
##-------------------------------------------
## Windows
git config merge.tool meld
git config merge.meld.cmd '"path/Meld.exe" $LOCAL $BASE $REMOTE --output=$MERGED'
Para Windows deve-se informar o caminho para o arquivo executvel, path,

alm de definir as trs verses que sero exibidas $LOCAL, $BASE e $REMOTE con-
forme vimos na figura 6.13. Ainda a opo --output=$MERGED, para informar
que o arquivo a ser editado ser sobrescrito sob a verso $MERGED, que criada
automaticamente pelo Git quando h conflitos.
Alternativamente pode-se editar o arquivo .gitconfig com as mesmas infor-
maes passadas ao comando git config. Para verificar como altera-se esse
arquivo, abra-o aps avaliar os comandos descritos. Ainda, se desejado que
essas opes sejam vlidas para todos os projetos Git de seu computador, a
opo --global em git config pode ser utilizada. Assim, quando avaliados
os comandos git mergetool e git difftool, o programa meld ser lanado
automaticamente.
Com isso, j temos nosso Git devidamente configurado para utilizar o progra-
mada meld e j observamos sua relevncia quando se trabalha com arquivos
versionados. Mas ainda, apresentamos somente uma das vrias interfaces que
se dispem a facilitar a visualizao de diferenas e mesclagem de arquivos.
Podemos citar as interfaces kdiff32 e P4Merge3 , como outras interfaces de
comparao bastante utilizadas em projetos versionados. Em geral, todos estes
programas seguem o mesmo estilo de exibio de arquivos que o meld e as
configuraes para torn-los programas de mergetool e difftoll padro so
as mesmas.
importante salientar que as ferramentas grficas apresentadas neste cap-
tulo no substituem totalmente os comandos via terminal, mas seu uso em
2 Disponvel para download em http://kdiff3.sourceforge.net/
3 Disponvel para download em https://www.perforce.com/product/components/
perforce-visual-merge-and-diff-tools
conjunto com estes facilitam o fluxo de trabalho adotado em um projeto sob

versionamento.
Captulo 7
Trabalhando em equipe
O Git uma ferramenta que aliada a outros servios web, como GitLab ou
GitHub, oferece funcionalidade e autonomia para se trabalhar. Contudo, com
tantos recursos disponveis, s sero bem aplicados quando todos os membros
do grupo, alm de conhec-los, trabalham em harmonia.
7.1 Boas prticas de colaborao

Repositrio onde so armazenados os arquivos de um projeto. Existem trs
nveis de acesso permitidos:
Private: o repositrio fechado, onde apenas o criador (Owner) tem

permisso de leitura e escrita. Se um repositrio privado for criado
dentro de um grupo, todos do grupo tero permisso de leitura e escrita.
Internal repositrio fechado para usurios externos ao grupo, mas qual-
quer usurio cadastrado no grupo ter permisso de leitura e escrita no
repositrio.
Public: repositrio aberto, visvel para qualquer pessoa (usurio do
grupo ou no). Usurios do grupo tem permisso de leitura e escrita no
repositrio. Usurios sem conta no grupo podem clonar o repositrio,
mas no tem permisso para alterar o repositrio (enviar merge requests
por exemplo).
possvel adicionar usurios para colaborar em um repositrio. Cada usurio

pode ter um nvel de acesso diferente: Guest, Reporter, Developer, Master.
Em permisses 1 possvel visualizar as habilidades concedidas para cada
nvel.
Logo aps criar um novo repositrio, recomendvel que se crie um arquivo
README.md. Independente da forma como o repositrio foi configurado,
sempre fundamental que ele contenha o arquivo README.md. Este arquivo
1 https://gitlab.c3sl.ufpr.br/help/permissions/permissions
115
116 CAPTULO 7. TRABALHANDO EM EQUIPE
sempre o primeiro a ser mostrado na pgina inicial de todo repositrio. Por

esse motivo, importante que o README.md contenha no mnimo:
Uma descrio geral do projeto;

Os nomes dos autores do projeto;
Instrues de instalao, no caso de softwares;
A licena do projeto (especialmente para projetos pblicos), ou uma
orientao sobre o uso do projeto (permisso, citao, entre outros).
Opcionalmente pode-se criar um arquivo LICENSE com a licena. Esse
arquivo ficar disponvel tambm em uma aba na pgina inicial do
projeto.
(Opcional): um guia de contribuio, se o (Owner) do projeto pretende
que usurios externos colaborem, possvel apresentar algumas orienta-
es bsicas sobre como colaborar. Criando um arquivo CONTRIBUTING.md
com este guia, ele ser automaticamente colocado em uma aba na pgina
inicial do projeto.
(Opcional): um changelog para que sejam registradas as modificaes
realizadas entre uma verso e outra (principalmente para softwares). Cri-
ando esse arquivo com estas informaes, ele aparecer automaticamente
em uma aba na pgina inicial do projeto.
Outra parte fundamental do Git, so os commits. Alm de salvarem as alte-

raes realizadas nos arquivos, tambm so responsveis por documentar as
alteraes feitas por qualquer usurio e em qualquer arquivo. Os commits
agilizam o processo de reviso do projeto, e poder ajudar futuros mantenedo-
res do projeto a desvendar o motivo de algum acrscimo ou modificao no
cdigo. Por causa dessas importncias, uma mensagem bem escrita a melhor
forma de se comunicar a alterao para os demais membros do grupo e para
voc mesmo. Essas mensagens tambm aparecero no git log do projeto,por
isso essencial que sejam bem escritas, de forma clara e sigam um padro.
Algumas regras de ouro, que so convenes gerais, para que um projeto
versionado com Git seja bem sucedido so:
Faa commits regularmente: isso faz com que as mudanas de cdigo

entre um commit e outro sejam menores, tornando mais fcil para todos
acompanhar as alteraes;
No faa commits de trabalhos pela metade: faa um commit apenas
quando tiver finalizado o que estava propondo. Isso ir forar voc
a deixar o trabalho em pedaos menores, e por consequncia realizar
commits regularmente;
Teste antes de fazer um commit: resista tentao de fazer um commit
que voc pensa que est completo. Teste toda a sua realizao para ter
certeza de que no causar um efeito colateral no projeto;
Escreva boas mensagens de commit: seja claro e objetivo ao escrever as
mensagens de commit. No entanto, tome cuidado para no ser vago,
ou escrever apenas mudana, mais mudanas, etc. Se uma mensagem
curta for suficiente, use git commit -m 'Mensagem', mas lembre-se de
ser informativo sobre a alterao realizada, para ser til para todos do
projeto.
7.1. BOAS PRTICAS DE COLABORAO 117
Existem outras convenes estabelecidas sobre como escrever mensagens de

commit contextualizadas, baseadas nas mensagens geradas por mensagens de
funes do prprio Git. Estas convenes podem resumidas nas 7 regras que
so convenes globais:
1. Separe o ttulo do corpo do texto com uma linha em branco: por padro,
a primeira linha o ttulo do commit, e deve ser uma mensagem curta.
Ao deixar uma linha em branco, permitido escrever uma mensagem
de qualquer tamanho, detalhando melhor as modificaes feitas. Dessa
forma, quando git log for executado, toda a mensagem de commit
aparecer, enquanto que git log --oneline mostrar apenas o ttulo do
commit.
2. Limite a linha de ttulo em 50 caracteres: isso faz com que o colabora-

dor pense mais para escrever uma mensagem mais informativa. Se a
mensagem for uma nica linha (git commit -m), ento esse limite pode
se estender para 72 caracteres.
3. Capitalize a mensagem: em todas as mensagens de commit comece com

letra maiscula, tanto se for ttulo, corpo da mensagem, ou apenas uma
mensagem de uma nica linha.
4. No termine os commits com ponto: principalmente se for o ttulo

de uma mensagem de commit mais longa. Espao valioso quando
dispomos apenas de 50 ou 72 caracteres.
5. Use o modo imperativo: no ttulo de commits longos ou em mensagens

de commits nicas. O modo imperativo significa escrever como se esti-
vesse dando um comando a algum. Seja direto e objetivo, e escreva no
presente. Exemplos de mensagens no imperativo:
- Adiciona verso final

- Altera pargrafo da introduo
- Remove funes precipitadas
Algumas mensagens no modo no imperativo so:
- Corrigindo o erro
- Mudando a funo
- Mais correes para mais funes
6. Limite o corpo da mensagem em 72 caracteres: ao escrever uma mensa-

gem de commit mais longa, devemos manter o corpo da mensagem com
no mximo 72 caracteres.
7. Use o corpo da mensagem para explicar o que e porque, e no

como: contextualize o que voc fez e o motivo. Na maioria dos casos
voc pode deixar de fora como voc fez as modificaes, pois o cdigo
alterado ser auto-explicativo.
7.2 Modelos de fluxos de trabalho
A escolha do workflow (fluxo de trabalho) depende de cada projeto e das

preferncias pessoais. Podemos utilizar as informaes sobre cada workflow,
e decidir qual mais adequado para cada projeto. Existem quatro maneiras
principais de trabalhar em colaborao com o Git e o GitLab:
7.2.1 Centralized workflow
Recomendado para projetos pequenos, e/ou que no necessitam de muitas

alteraes. Nesse workflow, o repositrio possui apenas um branch (master)
e as alteraes so feitas nesse branch. As revises s podero ser realizadas
depois que tudo foi enviado para o servidor remoto. Com isso, h uma grande
chance de ocorrerem conflitos.
Exemplo
Aps iniciar um repositrio central, os colaboradores devem clonar o reposit-
rio.
Depois de um colaborador terminar seu tra-
balho remotamente, ele publica as modifica-
es para o repositrio central, para que os
demais membros possam ter acesso.
Outro membro tambm termina seu traba-
lho e resolve publicar no repositrio central,
porm no conseguir. O repositrio central
est diferente do seu repositrio local.
Figura 7.1: Colaboradores clo-

nando o repositrio central.
Figura 7.2: Colaborador publi-

cando as modificaes no repo-
sitrio central.
Para conseguir enviar as modificaes realiza-
das, o colaborador precisa puxar as atualiza-
es feitas para o seu repositrio, integr-los
com as suas alteraes locais, e em seguida,
tentar novamente.
Figura 7.3: Colaborador no

conseguindo publicar as modi-
ficaes no repositrio central.
7.2. MODELOS DE FLUXOS DE TRABALHO 119
Aps feito isso, ser possvel o colaborador

fazer as modificaes.
Figura 7.4: Colaborador pu-

xando as modificaes do repo-
sitrio central.
7.2.2 Feature branch workflow
Recomendado para projetos pequenos e gran-

des, que envolvam mais de um colaborador.
O projeto principal mantido no branch
master. Se um membro quiser realizar al-
guma alterao, dever criar um novo branch
feature, e fazer as alteraes nesse branch
e sugerir um merge request. Com isso, os
demais colaboradores podero revisar as al-
teraes sugeridas e discutir as modificaes,
at que uma pessoa habilitada faa o merge
desse branch freature para o branch master.
Dessa forma, evita-se os possveis conflitos Figura 7.5: Colaborador pu-
e garante que tais alteraes no causaram blica modificaes do reposit-
algum problema. Esse workflow altamente rio central.
recomendado por ser simples de gerenciar,
evitar grandes conflitos, e ser relativamente
fcil para usurios novos do Git.
Exemplo
Antes de comear a desenvolver um recurso, preciso criar um ramo isolado
para trabalhar.
Com isso, o membro poder iniciar o seu tra-
balho, e realizar o que for necessrio nesse
ramo (branch). O colaborador, aps finali-
zar o projeto, ir requirir um merge request
para que as alteraes feitas nesse branch,
sejam incorporadas no master. Os demais
Figura 7.6: Criando um novo

ramo para o trabalho.
membros, podero avaliar se tais modifica-

es so pertinentes para o projeto.
Quando as alteraes sugeridas para o cola-
borador forem incorporadas o branch poder
ser movido para o master.
7.2.3 Gitflow workflow
Indicado para projetos maiores e/ou com

um grande nmero de colaboradores. Esse
workflow envolve a criao de alguns bran-
ches com funes especficas. Todo o desen-
volvimento realizado no branch develop.
Quando uma verso est pronta, ela mo- Figura 7.7: Colaborador solicita
vida para o branch release, onde testada e merge, e aguarda reviso dos
finalmente incorporada ao ramo master, que colaboradores.
contm apenas verses finais (estveis).
extremamente recomendado esse workflow
para desenvolvimento de softwares, porm exige de mais familiaridade com o
Git. Permite, por exemplo, que os usurios de um software, instalem tanto uma
verso estvel (do branch master) quanto uma verso em desenvolvimento (do
branch develop).
Exemplo
So criados branches com funes espec-
ficas, como no exemplo Hotfix, Release e
Develop.
Develop semelhante ao master do feature

branch workflow. Release serve para lanar
possveis bugs gerados no cdigo. Hotfix con- Figura 7.8: Movendo ramo para
o master.
tm as correes dos bugs do release que no podem aguardar o lanamento
do mesmo.
7.2.4 Forking workflow
Recomendado para projetos abertos, onde

se espera que usurios externos faam con-
tribuies. Esse workflow consiste em um
repositrio oficial, de onde os colaboradores
fazem um fork desse repositrio, e passam
a desenvolver o projeto de maneira indepen-
dente. Assim, cada colaborador poder ado-
tar o workflow de preferncia, e no preci-
sar ter acesso ao repositrio oficial, apenas
colaborar enviando merge.
Exemplo Figura 7.9: Ilustrao dos bran-
ches especficos.
7.3. FLUXO DE TRABALHO PET NO GITLAB 121
Criado o repositrio central, os colaboradores

fazem um forkpodero trabalhar de maneira
independente.
Independente da escolha do workflow para
cada projeto importante sempre informar
o mtodo que est sendo utilizado para seus
colaboradores, para que eles possam seguir
o mesmo padro.
Essas informaes podero ser descritas em
README.md ou no CONTRIBUTING.md.
7.3 Fluxo de trabalho PET

no GitLab
O PET-Estatstica UFPR possui um grupo no Figura 7.10: Ilustrao dos
Git para o desenvolvimento de projetos. Uti- forks de um projeto.
lizaremos a seguinte ilustrao para entender
o fluxo do trabalho do PET.
Conforme a demanda de projetos, criado o

repositrio para armazen-lo. Aps isso, so criados as milestones - marcado-
res de classificao dos arquivos. Esses passos so feitos no Owner.
Indo para o master, temos os seguintes pas-
sos:
Conforme a demanda do projeto, cri-

ado um issue para adio de contribui-
es;
Atualiza o ramo devel;
Aps isso, necessrio criar um branch
(ramo) para incluir as contribuies;
Entrando no developer, teremos o ciclo de

trabalho em que adiciona as modificaes
(git add), registra as mesmas (git commit)
e aps realizar todo o trabalho, feito o git
push enviando ao servidor remoto.
A prxima etapa a requisio de merge.

Com esse merge, feita as discusses a res-
peito da contribuio, assim podendo retor-
nar ao ciclo do developer para as devidas Figura 7.11: Ilustrao do fluxo
correes e sugestes. Aps a certeza dessa de trabalho do PET.
contribuio, movida para o ramo devel e
fechado o issue referente ao trabalho feito.
Depois de terminar todas etapas do projeto,
completa-se as milestones, realiza o merge
do devel no master, e cria a tag de verso.
Apndice A
Exemplos de rotinas
Neste apndice so descritas brevemente algumas das rotinas mais usuais em

projetos Git. A maioria dos exemplos esto detalhados na apostila e foram
resumidos nesta coletnea. Abaixo temos a lista de rotinas aqui presentes.
Rotinas
Rotina 1: Configurar usurio e e-mail localmente e globalmente. . . . 124

Rotina 2: Iniciar um projeto Git local. . . . . . . . . . . . . . . . . . . . 124
Rotina 3: Criar um ramo, incluir modificaes e fazer o merge em outro.124
Rotina 4: Visualizar diferenas entre referncias relativas, absolutas
(commits) e ramos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Rotina 5: Resolver conflitos de merge. . . . . . . . . . . . . . . . . . . . 126
Rotina 6: Visualizar o histrico de commits do projeto. . . . . . . . . . 126
Rotina 7: Voltar arquivos para verses anteriores. . . . . . . . . . . . . 127
Rotina 8: Refazer o ltimo commit para alterar a mensagem e/ou in-
cluir mais modificaes. . . . . . . . . . . . . . . . . . . . . . . . . 127
Rotina 9: Criar chaves pblicas para adicionar aos perfils em sevios
Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Rotina 10: Criar chaves pblicas e adicionar ao um servidor remoto. . 128
Rotina 11: Inicar um repositrio remoto Git em um servidor. . . . . . . 129
Rotina 12: Trabalhe remotamente. . . . . . . . . . . . . . . . . . . . . . . 129
Rotina 13: Manipule ramos remotos. . . . . . . . . . . . . . . . . . . . . 130
Rotina 14: Adicione endereo remoto. . . . . . . . . . . . . . . . . . . . . 131
Rotina 15: Remove ramos de demanda, locais e remotos, j incorporados
aos ramos permanentes. . . . . . . . . . . . . . . . . . . . . . . . . 132
123
124 ROTINAS
Rotina 1: Configurar usurio e e-mail localmente e globalmente.
## Configurando localmente
## - vlido para o repositrio atual
git config user.name "Name Lastname"
git config user.email "namelastname@servidor"
## Configurando globalmente
## - vlido para todos os repositrios do computador
git config --global user.name "Name Lastname"
git config --global user.email "namelastname@servidor"
## Obs.: As configuraes locais se sobrepem as

## globais, quando as duas forem avaliadas.
Rotina 2: Iniciar um projeto Git local.
## Em um diretrio que deseja-se versionar
## Inicia o versionamento Git

git init
## Verifica o estado do repositrio

git status
## Adicione os arquivos para receber o commit

git add file1.txt file2.R file3.txt file4.Rmd
## Registre a verso do repositrio com uma mensagem

## informativa
git commit -m "Inicia repositrio"
## Verifica o histrico de verses

git log
Rotina 3: Criar chaves pblicas para adicionar aos perfils em sevios Web.
## Cria uma chave pblica.

ssh-keygen -t rsa -C "namelastname@servidor"
## Exibe as chaves pblicas.

ROTINAS 125
## Adicione o contedo a um servidor remoto, como:

## - git@github.com
## - git@gitlab.com
## - git@gitlab.c3sl.ufpr.br
## Verifica conexo com o servidor

ssh -T endereo ## endereo = git@github.com, ...
## Obs.: Todos os comandos ssh so provinientes do

## pacote de funo ssh para shell, portanto para
## utilizar instale este pacote.
Rotina 4: Criar chaves pblicas e adicionar ao um servidor remoto.
## Cria uma chave pblica na sua mquina local.

ssh-keygen -t rsa -C "namelastname@servidor"
## Exibe as chaves pblicas criadas.

## Exibe as chaves autorizadas da sua conta no servidor remoto.

ssh user@caporal.c3sl.ufpr.br "cat ~/.ssh/authorized_keys2"
## Insere a chave gerada final do arquivo de chaves autorizadas.

ssh user@caporal.c3sl.ufpr.br \
"cat >> ~/.ssh/authorized_keys2" < ~/.ssh/id_rsa.pub
Rotina 5: Inicar um repositrio remoto Git em um servidor.
## Loga no servidor por SSH.

ssh user@caporal.c3sl.ufpr.br
## Criar um diretrio para conter o projeto. Apesar do final .git

## (opcional), um diretrio, no um arquivo.
mkdir -p ~/Documentos/meu1repo.git
cd ~/Documentos/meu1repo.git
## Inicia um repositrio remoto sem workspace.

git --bare init
git config --list
## Sai do servidor.
exit
126 ROTINAS
## Opo 1: Na mquina local, clonar o repositrio. O diretrio criado

## no tem o .git no final
git clone user@macalan.c3sl.ufpr.br:~/Documentos/meu1repo.git
cd meu1repo
git status
## Opo 2: Se o repositrio ja comeou localmente, ento apenas

## adicione o endereo do remoto.
git remote add origin \
user@macalan.c3sl.ufpr.br:~/Documentos/meu1repo.git
## Exibir os endereos remotos.

git remote -v
Rotina 6: Criar um ramo, incluir modificaes e fazer o merge em outro.
## Verifica os ramos existentes

git branch
git branch -l ## Apenas os locais
git branch -r ## Apenas os remotos
git branch -a ## Todos
## Cria um ramo, para trabalho especfico como:

## - Corrigir bugs
## - Desenvolver features
## - Tarefas em geral
git branch bugfix
## Altera versionamento para o ramo criado

git checkout bugfix
## Adiciona as alteraes que corrigem o bug

git add app.R
## Registra as alteraes
git commit -m "Altera delimitadores da funo"
## Retorna para o ramo principal

git checkout master
## Incorpora ao ramo principal as alteraes

## realizados no ramo bugfix
git merge bugfix
ROTINAS 127
## Deleta o ramo responsvel pela correo do bug

git branch -d bugfix
Rotina 7: Visualizar diferenas entre referncias relativas, absolutas (commits) e

ramos.
## -------------------------------------------
## Diferenas no commitadas
## Lista as diferenas entre o ltimo commit e o

## estado do repositrio no working directory
git diff
## Diferena para um nico arquivo

git diff file.Rmd
## -------------------------------------------
## Diferenas entre verses commitadas
## Verifica os registros com referncia

git reflog
## Lista as diferenas entre o ltimo e o

## antepenltimo registro
git diff HEAD~0 HEAD~2 ## ou pelo SHA1 ID
git diff 7204daa be1a9cc
## -------------------------------------------
## Diferenas entre ramos
## Lista diferenas entre os ramos master e

## feature1
## Obs.: Programas externos podem ser utilizados para

## visualizar diferenas, use difftool no lugar de
## diff, ver cap. 06
Rotina 8: Resolver conflitos de merge.
## Incorpora modificaes realizadas no ramo feature

git merge feature
128 ROTINAS
## Edite e salve o(s) arquivo(s) em conflito, as

## pores em conflito so destacadas por <<< === >>>
## Finaliza merge com o commit:

git commit -a -m "Merge do ramo feature"
Rotina 9: Visualizar o histrico de commits do projeto.
## Histrico de registros
git log
## Histrico de registros em uma linha com trajetria

## dos ramos
git log --graph --oneline
## Histrico de registro com referncia

git reflog
## Histrico de registro via interface grfica padro

gitk
gitk --all
Rotina 10: Voltar arquivos para verses anteriores.
## Verifica o histrico de verses do repositrio

## - Guarde o SHA1 ID do registro desejado: ec3650c8
git log --oneline
## -------------------------------------------
## Descartar todas as alteraes at um commit
git reset --hard ec3650c8
## Obs.: Reescreve a histria do repositrio, no

## recomendvel reescrever a linha do tempo quando
## se est em um projeto colaborativo remoto.
## -------------------------------------------
## Reverte o estado atual para um registro especfico
git revert ec3650c8
git commit -am "Retorna projeto para verso funcional"
## Obs.: Faz um merge da verso atual com a verso do

## SHA1 ID informado. Podem haver conflitos que devem
ROTINAS 129
## ser resolvidos para concluir a reverso.
## -------------------------------------------
## Cria um ramo provisrio a partir de um SHA1 ID
git checkout ec3650c8
## Visualiza os ramos existentes

git branch
## Cria um ramo denifitivo com o estado no SHA1 ID

git checkout -b ramo_teste
## Obs.: O ramo provisrio removido assim que se

## fizer um checkout para qualquer outro ramo
Rotina 11: Refazer o ltimo commit para alterar a mensagem e/ou incluir mais
modificaes.
## Verifica o histrico de verses do repositrio

git log --oneline
## Caso seja o objetivo, adicione mais modificaes.

git add script.R
## -------------------------------------------
## Reescreve a ltima mensagem de commit
git commit --amend -m "Correo de Commit"
## Obs1.: Arquivos na staging area tambm so

## incorporados ao ltimo commit
## Obs2.: Reescreve a histria do repositrio, no
## recomendvel reescrever a linha do tempo quando
## se est em um projeto colaborativo remoto.
Rotina 12: Trabalhe remotamente.
## Clona um projeto remoto:

## e.g. git@github.com:pet-estatistica/apostila-git.git
git clone endereo:namespace/project.git
## Realiza modificaes e/ou incluses de um ou

## vrios arquivos
130 ROTINAS
## Adiciona todas as alteraes para commit

git add .
## Registra suas alteraes

git commit -a -m "Modifica compilao do projeto"
## Envia as alteraes para o repositrio remoto (origin)

git push origin
## Traz estado do repositrio remoto

git pull origin
asdasd
asdas
Rotina 13: Manipule ramos remotos.
## -------------------------------------------
## Realizando contribuies em um ramo remoto
## Lista todos os ramos, locais e remotos

git branch -a
## Altera versionamento para o ramo issue01

git checkout issue01
## Traz estado do ramo remoto issue01

git pull origin issue01
## Realiza modificaes e/ou incluses de um ou

## vrios arquivos

git add .

git commit -a -m "Modifica lao iterativo condicional"
## Envia as alteraes no ramo para a verso remota

git push origin issue01
## -------------------------------------------
## Realizando contribuies em um ramo remoto e
ROTINAS 131
## enviando o ramo principal mesclado
## Traz estado do ramo remoto issue01

git pull origin bugfix
## Altera versionamento para o ramo issue01

git checkout bugfix
## Realiza modificaes e/ou incluses de em um ou

## vrios arquivos

git add .

git commit -a -m "Altera classe do objeto retornado"
## Retorna ao ramo principal

git checkout master
## Incorpora modificaes realizadas no ramo bugfix

git merge bugfix
## Envia as alteraes ao repositrio remoto

## Deleta o ramo bugfix

git branch -d bugfix ## Local
git push :bugfix ## Remoto
Rotina 14: Adicione endereo remoto.
## Lista os servidores remotos, com endereo

git remote -v
## -------------------------------------------
## Adicionando local para trazer contribuies
## Adiciona local remoto com nome gitlab:

git remote add gitlab git@gitlab.com:user/project.git
## Adiciona local remoto com nome github:

git remote add github git@github.com:user/project.git
## Atualiza arquivos locais, baseado no local remoto:

git pull gitlab ## gitlab.com:namespace/project.git
132 ROTINAS
git pull github ## github.com:namespace/project.git
## -------------------------------------------
## Adicionando local para enviar contribuies
## Lista os locais de origem

git remote show origin
## Adiciona novo local de origem:

## e.g. git@github.com:pet-estatistica/apostila-git.git
git remote set-url origin --push --add endereo_remoto
## Envia as contribuies para os locais remotos

git push origin
Rotina 15: Remove ramos de demanda, locais e remotos, j incorporados aos

ramos permanentes.
## Listar os ramos:
git branch -l ## Locais
git branch -r ## Remotos
git branch -a ## Todos
git branch --merged ## Incorporados ao atual
## Remove ramos:
git branch -d bugfix ## Locais
git branch -dr origin/bugfix ## Remotos
git push --delete origin bugfix ## No origin
git push origin :bugfix ## Idem o anterior
## Remove todos os ramos LOCAIS com 'issue' no nome.

git branch -l --merged | grep "issue" | xargs -n 1 git branch -d
## Remove todos os ramos REMOTOS com 'issue' no nome.

git branch -r --merged | grep "issue" | xargs -n 1 git branch -dr
## Acima da verso 2.5.0 pode-se usar

git branch -d `git branch l --merged`
git branch -dr `git branch r --merged`
Apndice B
Dicionrio de termos
B.0.1 Config
O config um comando usado para ajustar as configuraes padro do Git. H

duas configuraes bsicas a serem feitas: a incluso do e-mail e do nome do
usurio Git. Todas as configuraes definidas como globais ficam armazenadas
em um arquivo chamado .gitconfig, que fica localizado no diretrio padro
do usurio.
Exemplo:
# Configurando o usurio Ezio Auditore:

git config --global user.name "Ezio Auditore"
# Configurando o e-mail:
git config --global user.email ezio.auditore@exemple.com
B.0.2 SSH Key
uma chave de autenticao baseada em criptografia de chave pblica (chave

assimtrica). Essa criptografia torna o processo de transferncia de arquivos
entre o cliente e o servidor mais segura.
Para que o Git local consiga se conectar a um servidor Git remoto, necessrio
que esta chave seja gerada e que as devidas configuraes sejam feitas tanto
localmente quanto no servidor remoto, caso contrrio, exibido um erro e a
conexo interrompida.
Exemplo:
# Gerando chave SSH:

ssh-keygen
133
134 APNDICE B. DICIONRIO DE TERMOS
B.0.3 Help
Todo comando Git tem um manual de ajuda que pode ser exibido na tela com
o comando --help.
Exemplo:
# Exibir ajuda do comando status:

git status --help
B.0.4 Repositrio
Um repositrio uma pasta gerenciada pelo Git. A partir da criao desta,

usufrumos do sistema de versionamento, sendo possvel transitar entre as
diferentes verses a medida que necessrio.
Exemplo:
# Iniciar repositrio na pasta atual:

git init
B.0.5 Stagin Area
A stagin area um espao temporrio na pasta gerenciada pelo Git. o local

em que ficam os arquivos antes de serem marcados como uma verso definitiva.
Em traduo livre, stagin area rea de estgio, podemos assim imaginar que
o arquivo est estagiando antes de ser promovido a um arquivo definitivo.
B.0.6 Remote
O remote mostra o servidor remoto onde os arquivos Git esto hospedados.

O remote padro geralmente criado com o nome de origin, mas possvel
adicion-lo utilizando outros nomes e at mesmo adicionar outros servidores
remotos juntamente ao origin.
Exemplo:
# Adicionando um servidor remoto com nome origin:

git remote add origin "git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git"
B.0.7 Clone
O clone usado quando deseja-se clonar um repositrio que est disponvel

em um servidor remoto para o servidor local. Depois da clonagem, estar
disponvel todos os arquivos e todo o histrico de controle de verses sem a
necessidade de uso da internet.
135
importante salientar que quando se usado o clone, o servidor remoto

adicionado automaticamente, podendo ser acessado atravs do comando
origin.
Exemplo:
# Clonando o projeto desta apostila:

git clone git@gitlab.c3sl.ufpr.br:pet-estatistica/apostila-git.git
# Exibindo os servidores remotos:
git remote
B.0.8 Status
O status exibe a diferena entre o estado atual dos arquivos e o estado do

ltimo commit do mesmo branch. So trs estados possveis: consolidado
(committed), modificado (modified) e preparado (staged).
Exemplo:
# Pedindo o status:
git status
B.0.9 Add
O add adiciona (envia) os arquivos para a stagin area, para que possa ser
marcado no tempo por um commit.
Exemplo:
# Adicionar todos os arquivos a stagin area:

git add *
B.0.10 Commit
O commit marca os arquivos da stagin area como uma verso definitiva, para
que posteriormente, caso algum erro ocorra, possamos voltar nos commits
anteriores onde o cdigo est em pleno funcionamento.
Exemplo:
git commit -m "Meu primeiro commit"
B.0.11 Branch
Os branchs so como uma cpia dos arquivos do ultimo commit para um

ambiente de desenvolvimento paralelo, o que permite que as modificaes em
um branch no afete os arquivos em outro. Os branchs tambm so chamados

de ramos de desenvolvimento. Veja com mais detalhes nos captulos 3 e 7.
Exemplo:
# Cria um branch chamado novoBranch

git branch novoBranch
B.0.12 Checkout
O checkout serve para transitar entre branchs e commits. Usando o checkout

possvel voltar a commits anteriores.
Exemplo:
# Mudar do branch atual para o branch teste:

git checkout teste
B.0.13 Merge
Com o merge possvel a fuso de dos dois ramos em um.

Quando se trabalha em ramos diferentes (diferentes branchs) e precisa-se
posteriormente juntar o trabalho, o merge (fundir) usado, permitindo que o
trabalho seja centralizado novamente. A fuso feita de forma automtica,
mas conflitos podem ocorrer, como por exemplo, quando duas ou mais pessoas
modificam a mesma parte do cdigo. Estes conflitos devem ser resolvidos
manualmente, deixando a cargo do gerente de projetos decidir que parte do
cdigo deve permanecer.
Exemplo:
# Faz merge do branch chamado novoBranch com o branch atual:

git merge novoBranch
B.0.14 Rm
O git rm, na sua forma mais comum, serve para remover um arquivo de
forma que ele deixe de ser gerenciado pelo Git e seja excludo do disco rgido.
Tambm possvel que o arquivo deixe de ser gerenciado e permanea no
disco.
Uma das vantagens que, quando o arquivo removido pelo git rm, j aparece
como preparado (staged), precisando somente que a excluso seja commitada.
Exemplo:
137
# Remover arquivo teste.tex do gerenciamento e do disco:

git rm teste.tex
# Remover arquivo teste.tex apenas do gerenciamento:

git rm --cached teste.tex
B.0.15 Mv
O git mv move ou renomeia arquivos informando ao Git.

Caso a mudana seja feita sem esse comando, o Git entende que o arquivo foi
deletado e que um novo arquivo foi criado, deixando de fora, por exemplo, a
ligao existente entre o arquivo e seus commits.
Exemplo:
# Renomeando o arquivo teste.tex para arquivo1.tex:

git mv teste.tex arquivo1.tex
B.0.16 Push
O push usado para empurrar os arquivos do repositrio local para o

servidor remoto.
Exemplo:
# Atualizado o branch master (remoto), com o branch atual (local):

B.0.17 Fetch
O fetch atualiza o repositrio local com as alteraes do remoto, porm no

realiza o merge dos arquivos, deixando isso para ser feito manualmente.
Exemplo:
# Buscando arquivos no servidor remoto origin:

git fetch origin
B.0.18 Pull
O pull semelhante ao comando fetch, porm, puxa os arquivos do servidor

remoto fazendo merge. Caso haja algum conflito de merge, estes devero ser
resolvidos manualmente.
Exemplo:
# Puxando arquivos no servidor remoto origin:

git pull origin
B.0.19 HEAD
HEAD um arquivo que contm um apontador para o branch atual. Quando

o checkout executado para a mudana do branch, esse arquivo automati-
camente modificado, apontando agora para o novo local, e assim permitindo
que, quando o computador for desligado e depois de reiniciado o Git ainda
esteja trabalhando com o mesmo branch.
B.0.20 Tag
As tags so usadas para marcar pontos especficos do desenvolvimento. Geral-

mente so usadas para marcar verses definitivas, como a v1.0, v2.0 e assim
por diante.
Elas so divididas em dois tipos: leve e anotada. A tag leve simplesmente

aponta para um commit especfico. J a tag anotada guardada como objetos
inteiros, possuindo algumas informaes, como o nome da pessoa que criou, a
data, uma mensagem semelhante a de commit, entre outras.
Exemplo:
# Criando tag leve:

git tag -l "v1.0.0"
# Criando tag anotada:

git tag -a v1.0 -m "Minha primeira tag anotada."
B.0.21 Stash
Com este comando no necessrio fazer um commit para mudar de branch.

Ao execut-lo, os arquivos modificados ficam salvos em uma pilha de modifi-
caes inacabadas, sendo possvel transitar entre branchs e voltar ao trabalho
inacabado quando necessrio.
Exemplo:
# Fazendo o stash:
git stash
# Listando os stash criados:
git stash list
139
B.0.22 Reset
Enquanto o git checkout somente transita entre os commits, o reset pode

tambm alterar o histrico, fazendo commits serem apagados de maneira
irreversvel (hard) ou serem apenas retornados ao estado de no commitado
(soft).
Exemplo:
# Apagando o ltimo commit (voltando ao anterior):

git reset --hard HEAD~1
B.0.23 Rebase
O rebase usado para modificar commits antigos. Ele refaz a rvore de

commits, sendo assim no uma boa ideia fazer um push da alterao, pois
modificar a rvore do servidor afetando todos os desenvolvedores.
A ideia geral rebase apaga os commits de um ramo e muda de base,
passando-os para novos commits do ramo atual, formando uma rvore com
fluxo de trabalho linear.
Exemplo:
# Fazer o rebase do branch teste para o atual:

git rebase teste
B.0.24 Blame
Pesquisa qual commit modificou determinado arquivo, com o objetivo de

encontrar quem e quando um erro foi inserido. Esse mtodo tambm
chamado de anotao de arquivo.
Exemplo:
# Fazer
B.0.25 Bisect
O bisect realiza uma pesquisa binria (binary search) a procura de erros. Para
que a pesquisa ocorra, necessrio um ponto no tempo em que o cdigo esteja
funcionando e outro que no esteja.
Exemplo:
# Pesquisa Binria:
# Iniciando a pesquisa.
git bisect start
# Marcando o commit atual como no funcionando.
git bisect bad
# Marcando o commit com nome commit1 como funcionando:
git bisect good commit1

Apostila Git

Enviado por

Direitos autorais:

Formatos disponíveis

Apostila Git

Enviado por

Dados do documento

Descrição original:

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

Apostila Git

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal do Paran

Paul Bear Bryant

1 Sistemas de controle de verso 9

5 Servios Web para Projetos Git 67

7 Trabalhando em equipe 115

A Exemplos de rotinas 123

B Dicionrio de termos 133

Inicialmente, podemos dizer que Git um Sistema de Controle de Verso,

Ento, utilizar o Git a garantia de um sistema robusto de controle de versio-

Agora, devidamente apresentados ao sistema de versionamento Git vamos

Usurios Windows devem visitar Git for Windows1 , clicar em Download e

Figura 2.1: Printscreen do passo 1

Figura 2.2: Printscreen do passo 2

Figura 2.3: Printscreen do passo 3

No passo 4, representado pela figura 2.4, o instalador nos oferece a oportu-

Figura 2.4: Printscreen do passo 4

Figura 2.5: Printscreen do passo 5

Figura 2.6: Printscreen do passo 6

Figura 2.7: Printscreen do passo 7

Figura 2.8: Printscreen do passo 8

Feito isso, Next, Finish e o Git est instalado.

Em qualquer sistema Linux, pode-se utilizar o gerenciador de pacotes da

sudo add-apt-repository ppa:git-core/ppa

Agora, execute o comando abaixo para instalao do Git. Siga as instrues

sudo apt-get install git git-core git-man git-gui git-doc \

Para adicionar ferramentas complementares, execute:

sudo apt-get install gitk meld

pacman -S git openssh meld

yum install git

Usurios de outra verso do Linux podem visitar Download for Linux2 .

sudo port install git-core

2.2 Configurando Perfil

As configuraes vo determinar algumas opes globais do Git, sendo neces-

Os comandos abaixo vo configurar o nome de usurio e endereo de e-mail.

Figura 2.9: Printscreen do passo 9

ou seja, as configuraes ficaro associadas ao trabalho em desenvolvimento,

git config --global user.name "Knight Rider"

git config user.name "Knight Rider"

Uma vez configurado o perfil, o Git est pronto para uso.

Os atalhos no Git so chamados de Alias. Com ele podemos mapear comandos

git config --global alias.nome_do_alias "comando inteiro"

Um exemplo bem simples o seguinte:

git config --global alias.st "status"

Assim, ao executar git st o mesmo que executar git status.

Pelo arquivo /.gitconfig:

Obs: Os arquivos de configurao do Git no tem extenso.

2.2.3 Ignorar Arquivos

Usando o arquivo .gitignore podemos ignorar arquivos que no desejamos

A primeira linha fala para o Git ignorar qualquer arquivo finalizado em .o

git config --global core.excludesfile ~/.gitignore

3.1 Instrues do Git

## Apenas verificando o cadastro.

## Padro de instrues Git.

cd meu1repo ## Diretrio de teste de comandos

## Padro de instrues Git.

## Ajuda resumida do Git, principais comandos com descrio.

usage: git [--version] [--help] [-C <path>] [-c name=value]

available git commands in '/usr/lib/git-core'

git commands available from elsewhere on your $PATH