GIT guia completo

Eng. MSc. Jadson Santos
GIT
O sistema de controle de versão distribuído mais
popular para Java com Eclipse

GIT
• Em 2002 o kernel do Linux usava o BitKeeper um DVCS
proprietário.
• Em 2005 essa ferramenta deixou de ser livre.
• Isso levou Linus Torvalds a desenvolver seu próprio
sistema de controle de versão baseado em algumas
lições que ele aprendeu enquanto usava o BitKeeper
• Velocidade
• Design Simples
• Forte suporte a desenvolvimento não linear
• Distribuído
• Capacidade de suportar projetos grandes como o kernel do Linux é
31/01/17 GIT

GIT
• Git é um sistema de controle de versão distribuído e um
sistema de gerenciamento de código fonte, com ênfase
em velocidade.
• Cada diretório de trabalho do Git é um repositório com um
histórico completo e habilidade total de
acompanhamento das revisões, não dependente de
acesso a uma rede ou a um servidor central.
31/01/17 GIT

GIT
• Diferentemente dos outros sistemas de controle de
versão (SVN) que guardam os arquivos e o delta das
mudanças realizadas nesses arquivos, o GIT guarda as
informações como um conjunto de snapshosts do
repositório.
• Em todo commit realizado, o GIT tira uma fotografia e
guarda uma referência a essa fotografia.
31/01/17 GIT

GIT Vantagens
• Git permite e encoraja você ter múltiplas branches locais.
• Permite criar uma nova branch para cada tarefa trabalhada, não
afetando as mudanças realizadas em outra tarefa
• Pode fazer experimentos sem afetar os demais códigos que vocês
está trabalhando
31/01/17 GIT

GIT Vantagens
• Git é rápido
• Quase todas as operações são realizadas localmente
• É escrito em C, reduzindo o overhead das linguagem de alto nível.
31/01/17 GIT
O tempo de se fazer um clone de um repositório inteiro (branches, tags) é equivalente ao
tempo do checkout do SVN, que não baixa o repositório

GIT Vantagens
• Git é distribuído
• Todos desenvolvedores tem um backup inteiro do repositório
• Confiança dos Dados
• Todo arquivo e commit no GIT possui um checksum e pode ser
recuperado a partir desse checksum
• Staging Area
• Área intermediária onde os commits podem ser revisados antes de
realizar o commit.
• Free and Open Source
31/01/17 GIT

GIT Desvantagem
• Mais complexo e uma curva de aprendizado maior para
ser usado
31/01/17 GIT
SVN
Checkout
Synchronize
Commit
Update
Merge
GIT
Init
Clone
Commit
PUSH
PULL
Fetch
Merge
Rebase
Amend
Cherry Pick
Apply Patch
Add to index
...

Controle de Versão Centralizado
31/01/17 GIT
Commit 1
Commit 2
Commit 3
...
Commit N

Controle de Versão Distribuído
31/01/17 GIT
Commit sdfl230dss
Commit k0sddslds Commit asdfghj23f
Commit wloelkco42k

GIT Organização dos Commits
• Commits dentro de uma mesma branch possuem uma
sequencia organizada com ponteiros
31/01/17 GIT
z
y
Branch 1
x

• Diferentemente do SVN, que o commit 10 vem depois do
commit 9, sistemas distribuídos não podem manter essa
ordem, pois o commit é local e não é possível saber que
commit veio antes do outro.
• Por isso, cada commit no GIT é identificado por um hash,
não por números sequenciais e essa ordem de commits é
mantida por meio de ponteiros. Um commit aponta para o
pai dele. E o pai só pode ter 1 commit filho.
31/01/17 GIT

• Situação não suportadas pelo GIT
31/01/17 GIT
z
y
Branch 1 Branch 2
y
xx
w
Erro!!!
z
Erro!!!

• Sempre que a ordem dos ponteiros não tiver igual a
última vez que você sincronizou com o repositório remoto,
será preciso reordenar com as operações de merge ou
rebase.
• Se não ocorrerá o famoso erro “non fast forward”
• Essa organização dos commits é o ponto mais
importe para se começar a trabalhar com o GIT
31/01/17 GIT

31/01/17 GIT
2
LOCAL REMOTO
2
11
PULL

31/01/17 GIT
2
LOCAL REMOTO
2
11
PULL
4 Commit de outra pessoa

31/01/17 GIT
3
2
LOCAL REMOTO
2
11
PULL
4
Seu Commit
Commit de outra pessoa

31/01/17 GIT
3
2
LOCAL REMOTO
2
11
ERRO!!!
Non fast forward
PULL
4PUSH
Seu Commit
Commit de outra pessoa

31/01/17 GIT
3
2
LOCAL REMOTO
2
11
PUSH successful
PULL
4
PUSH
REBASE
4
FETCH
3

GIT Instalação
• http://git-scm.com/downloads
31/01/17 GIT

GIT Instalação
• Para quem usa Linux
31/01/17 GIT

GIT Instalação
• Para quem usa MacOS
31/01/17 GIT

GIT Instalação
• Para quem usa Windows
31/01/17 GIT

GIT Instalação
• Para quem usa Windows é instalado também um
interpretador de comando que imita os do Linux
31/01/17 GIT

EGIT
31/01/17 GIT
EGit é o plugin padrão do Eclipse para o sistema de controle
de versão GIT
O projeto EGit está implementando em cima da
implementação JGit, biblioteca Java para Git
Já vem por padrão nas distribuições do eclipse mais
recentes.

EGIT
31/01/17 GIT
EGit vem por padrão no eclipse
Windows -> Show View -> Git -> Git Repositories

31/01/17 GIT
Conceitos e Principais
Comandos do GIT

• A primeira coisa a fazer depois da instalação é configurar
o seu nome e e-mail para assinar os seu commits
• Todo commit no Git deve ser assinado com nome e e-email
• Usando o comando git config
31/01/17 GIT
GIT CONFIG POR LINHA DE COMANDO

• key = user.name
• value = Nome Usuário
31/01/17 GIT
GIT CONFIG PELO ECLIPSE
Windows -> Preferences -> Team -> Git -> Configuration
-> Add Entry

• Permite excluir arquivos que não devem ser versionados,
por exemplo: arquivos de configuração ou arquivos
binários.
• Com o Git é muito fácil ignorar arquivos que não devem ser
comitados no controle de versão
• Obs.: Os arquivos ignorados não podem estar versionados. Você
deve remover antes do controle de versão para de fato eles serem
ignorados
31/01/17 GIT
GIT IGNORE
Remove os
arquivos de
configuração do
eclipse
e o diretório de
saída da build

• Inicia um novo repositório local sem estar associado a um
remoto
31/01/17 GIT
GIT INIT POR LINHA DE COMANDO

31/01/17 GIT
GIT INIT PELO ECLIPSE
Windows -> Show View -> Git -> Git Repository -> Create a
new Git Repository and add it to this view

31/01/17 GIT
Your
Computer
GIT CLONE
Local
Repository
Remote
Repository
Cria uma cópia de um repositório remoto na sua máquina local
Clone

• Usando o comando git clone via https
31/01/17 GIT
GIT CLONE POR LINHA DE COMANDO

31/01/17 GIT
GIT CLONE PELO ECLIPSE
Windows -> Show View -> Git -> Git Repository -> Clone a Git
Repository and add the clone to this view

• Git clone via https
31/01/17 GIT
https://github.com/jadsonjs/Test.git
Usando https é
preciso colocar
usuário e senha

• Git clone via ssh
• A vantagem de usar ssh é que, uma vez que você criou
o arquivo com a chave, não precisa ficar digitando
usuário e senha para realizar as operações.
31/01/17 GIT

31/01/17 GIT
Sua Chave Pública
Salvar Chave Privada
• Criando sua chave ssh pelo eclipse
• Eclipse -> Preferences -> General -> Network
Connections -> SSH2 -> Key Management -> Generate
RSA Key

31/01/17 GIT
Chaves privadas
carregadas pelo eclipse
É possível criar várias chaves RSA ou copiar a mesma chave
para computadores diferentes.
Se você copiar uma chave de um computador para outro, tenha
certeza que ela esteja carregada no eclipse. Apenas colocar
no diretório .ssh não é suficiente.

31/01/17 GIT
GIT CLONE
• Adicione a chave pública criada no Repositório remoto
• No GitHub vá em settings -> SSH keys -> Add SSH key

31/01/17 GIT
GIT CLONE
• Adicione a chave pública criada no Repositório remoto
• No GitLab vá em Profile Settings -> SSH keys -> Add SSH key

• Git clone via ssh
31/01/17 GIT
git@github.com:jadsonjs/Test.git

31/01/17 GIT
Diretório com
o código fonte
Branches locais
Branches Remotas
Commits iguais,
seu código está
atualizando em
relação ao remoto
Equivalente ao
comando “git status”
• Visão Geral do Repositório Local no Eclipse

31/01/17 GIT
Ao fazer o clone, por padrão é criada uma
branch master local a partir da branch master
remota

31/01/17 GIT
• Para abrir o projeto no Eclipse é necessário importar o
projeto para o workspace do Eclipse

• Permite associar um repositório remoto a uma repositório
local já existente.
• Necessário quando você não fez o clone, apenas usou o
init e agora quer enviar as informações para um
repositório remoto ou quando você quer associar mais de
um repositório remoto ao mesmo repositório local ( ver
slides trabalhando com múltiplos repositórios )
• Usando o comando git remote via https
31/01/17 GIT
GIT ADD REMOTE POR LINHA DE COMANDO

• Windows -> Show View -> Git -> Git Repository
31/01/17 GIT
GIT ADD REMOTE PELO ECLIPSE

• Permite visualizar o status do seu repositório local em
relação ao remoto
• Usando o comando git status:
31/01/17 GIT
Existe 1 commit local que precisa ser enviado para o repositório
remoto e existe 1 commit remoto que não está no repositório local
master: Sua branch local
origin/master: Branch remota que você está associado no momento
GIT STATUS POR LINHA DE COMANDO

• Existe 1 commit local que precisa ser enviado para o
repositório remoto e existe 1 commit remoto que não está
no repositório local
31/01/17 GIT
GIT STATUS PELO ECLIPSE

• Existem 2 commits no repositório local que não estão no
remoto
31/01/17 GIT
Commits diferentes
GIT STATUS PELO ECLIPSE

GIT Conceitos
31/01/17 GIT
Your
Computer
GIT COMMIT
Local
Repository
Remote
Repository
Commit
Um Commit para o GIT é uma operação que apenas
registra a mudança no seu repositório local

• 3 passos
• Criar um novo arquivo
• Adicionar à staging area
• Realizar o commit
31/01/17 GIT
GIT COMMIT POR LINHA DE COMANDO

31/01/17 GIT
GIT COMMIT PELO ECLIPSE

31/01/17 GIT
Classes Selecionadas
Equivalente ao
comando “git add”
Mensagem do commit
Todos devem ser
Assinados com o e-mail
GIT COMMIT e GIT ADD PELO ECLIPSE

31/01/17 GIT
Add to index = seleciona quais classes alteradas serão comitadas
Replace with HEAD revison = Reverte as alterações realizadas não comitadas
Commit pela Staging Area:
Windows -> Show View -> Git -> Staging Area
GIT COMMIT PELO ECLIPSE

• Mostra o histórico de commits no seu repositório local
• Comando git log:
31/01/17 GIT
GIT LOG POR LINHA DE COMANDO

31/01/17 GIT
GIT LOG PELO ECLIPSE
Windows -> Show View -> Git -> Git Repository -> Show in -
> History

GIT Conceitos
31/01/17 GIT
Your
Computer
GIT PUSH
Local
Repository
Remote
Repository
PUSH
Um PUSH envia essa mudança do seu repositório local para repositório
remoto

31/01/17 GIT
Origin é o nome padrão do repositório que você clonou
Master é a branch que você está enviando
GIT PUSH POR LINHA DE COMANDO

• Só depois do PUSH o arquivo apareceu no remoto
31/01/17 GIT
GIT PUSH POR LINHA DE COMANDO

31/01/17 GIT
GIT PUSH PELO ECLIPSE

31/01/17 GIT
Branch local Onde você tá Para qual remota irá enviar

31/01/17 GIT
 O Egit possui um atalho chamado “Push to Upstream” que envia um
push diretamente para uma branch remota de mesmo nome da branch
local
 Exemplo: se você estiver na branch local minha_branch, o Push to
Upstream enviar as mudanças diretamente para a branch remota
refs/heads/minha_branch

GIT Conceitos
31/01/17 GIT
Your
Computer
GIT PULL
Local
Repository
Remote
Repository
PULL
Um PULL recupera as mudanças do repositório remoto para o local

31/01/17 GIT
GIT PULL POR LINHA DE COMANDO

31/01/17 GIT
GIT PULL PELO ECLIPSE

EGIT Conceitos
31/01/17 GIT
Your
Computer
GIT AMEND
Local
Repository
Remote
Repository
Commit 1
Amend serve para “corrigir” um commit realizado anteriormente. As
mudanças são “concatenadas” ao último commit realizado na branch
sem gerar um novo commit
Commit 2
Amend

31/01/17 GIT
GIT AMEND POR LINHA DE COMANDO

31/01/17 GIT
GIT AMEND PELO ECLIPSE
Realizar um commit normal

31/01/17 GIT
Selecionar a opção Amend
Permite editar a mensagem e adicionar novas
classes ao commit anterior
GIT AMEND PELO ECLIPSE

GIT Conceitos
31/01/17 GIT
Your Computer
GIT BRANCHING
Local Repository Remote
Repository
Clone
MasterMasterBranch_1
Criação de Branches locais

31/01/17 GIT
GIT BRANCHING POR LINHA DE COMANDO
Criando uma Branch local
Apagando a Branch local

31/01/17 GIT
Enviando da “branch_1” local para a “master” remota do
servidor “origin”
GIT BRANCHING POR LINHA DE COMANDO
Realizando um PUSH a partir da branch

31/01/17 GIT
• Para criar um branch local a partir da master remota,
clicar em cima da master remota e utilizar a opção create
branch...
GIT BRANCHING PELO ECLIPSE

31/01/17 GIT
Marca a branch que você está no momento

31/01/17 GIT
Apagando a Branch local

31/01/17 GIT
Branch local Onde você tá Para qual remota irá enviar
Realizando um PUSH a partir da branch

EGIT Conceitos
31/01/17 GIT
Your Computer
Local Repository
MasterBranch_1
GIT Checkout
c0
c1
c0
c1
c2
git checkout branch_1
No git, o checkout é a operação de mudar de branch
Ptr

31/01/17 GIT
• ou
GIT CHECKOUT POR LINHA DE COMANDO

31/01/17 GIT
GIT CHECKOUT PELO ECLIPSE
Clica em cima da branch local e checkout

31/01/17 GIT
• Equivalente ao comando git checkout –b nome_da_banch
GIT CHECKOUT PELO ECLIPSE

GIT Conceitos
31/01/17 GIT
Your
Computer
GIT FETCH
Local
Repository
Remote
Tracking
Remote
Repository
FETCH
O FETCH apenas atualiza a sua referência ao repositório
remoto na área chamada de: “Remote Tracking”
Referência local ao repositório remoto

31/01/17 GIT
GIT FETCH POR LINHA DE COMANDO

31/01/17 GIT
GIT FETCH PELO ECLIPSE
Clica em cima do repositório e na opção Fetch from Upstream
O fetch recupera todas as mudanças em todas as branches remotas
para o repositório local, mas não aplica as mudanças nas
branches locais.

GIT Conceitos
31/01/17 GIT
Your Computer
Local Repository
MasterBranch_1
GIT MERGE
c0
c1
c0
c1
c2
c5
c3
1º git checkout –b branch_1
2º git commit – m “c2”
3º git checkout master
5º git merge branch_1
4º git commit –m “c3”

31/01/17 GIT
GIT MERGE POR LINHA DE COMANDO
A branch onde eu estou agora com essa

31/01/17 GIT
GIT MERGE PELO ECLIPSE
1º Realizar um commit local
2º Recuperar as mudanças do removo com o FETCH

31/01/17 GIT
Com o FETCH as mudanças estão na branch remota
2º Clicar em cima dessa branch remota e usar a opção MERGE para
trazer o novo commit para a branch local que você está no momento.

31/01/17 GIT
Repare após o merge os commits continuam diferentes, não existe
nada novo a ser recuperado, mas existem agora 2 commits para serem
enviados.
Ou seja, o merge reorganizou a ordem dos commits nesse repositório
criando um novo commit para as alterações remotas e colocando
depois do seu commit local

31/01/17 GIT
Se existissem conflitos, o MERGE tentaria resolvê-los e
se não conseguisse, pararia e mostraria esses conflitos
para você resolvê-los

GIT Conceitos
31/01/17 GIT
Your
Computer
GIT PULL (FETCH + MERGE)
Local
Repository
Remote
Tracking
Remote
Repository
FETCHMERGE
O comando GIT PULL na verdade é uma atalho para a realização de
dois comandos FETCH + MERGE
O PULL atualiza a sua referência ao repositório remoto com O
FETCH e aplica as mudanças no código local com o MERGE

GIT Conceitos
31/01/17 GIT
Your Computer
GIT REBASE
Local Repository Remote
Tracking
Remote
Repository
FETCH
Coloca o seu commit no topo da pilha de commits, como se você tive
começado a alterar o código com a versão mais nova do repositório
remoto.
Em caso de conflitos, solicitará para você resolvê-los
REBASE
Novo commit remoto
Novo commit local

GIT Conceitos
31/01/17 GIT
Your Computer
Local Repository
MasterBranch_1
GIT REBASE
c0
c1
c0
c1
c2
c3
5º git rebase branch_1
c2

31/01/17 GIT
GIT REBASE POR LINHA DE COMANDO

31/01/17 GIT
GIT REBASE PELO ECLIPSE
1º Recuperar as mudanças do removo com o FETCH

31/01/17 GIT
Com o FETCH as mudanças estão na branch remota
2º Clicar em cima dessa branch remota e usar a opção Rebase on
para trazer os novos 2 commits para a branch local que você está no
momento.

31/01/17 GIT
Repare que os commits então iguais agora e não existe nada novo a
ser recuperado, o seu repositório local estão igual ao remoto

31/01/17 GIT
GIT REBASE
Se existissem commits locais novos, esse commits
seriam reordenados para depois dos 2 commits remotos
recuperados. Reestabelecendo assim uma ordem para
os commits nesse repositório
Diferentemente do MERGE o REBASE só reorganiza os
commits, não gera um novo.
Se existissem conflitos, o rebase pararia e mostraria
esses conflitos para você resolvê-los, como não houve,
o rebase terminou com sucesso.

GIT Conceitos
31/01/17 GIT
Local Repository
MasterBranch_1
GIT MERGE X GIT REBASE
c0
c1
c0
c1
c2
c3
Local Repository
MasterBranch_1
c0
c1
c0
c1
c2
c5
c3 c3
c0
c1
c2
c0
c1
c2

31/01/17 GIT
GIT MERGE x GIT REBASE
Os dois reorganizam os commits para poder realizar o
push.
Após o Merge as branches apontam para o mesmo commit
Após o Rabase a branch integrada possue os commits
ordenados de forma linear

31/01/17 GIT
GIT MERGE x GIT REBASE
Qual usar?
Rebase é melhor para integrar mudanças
em branches que seguem o mesmo fluxo de
desenvolvimento, por exemplo quando se deseja
atualizar a branch local com a remota, já que o
fluxo de commits fica linear e o histórico mais
organizados
Merge é melhor para integrar mudanças entre
branches que seguem um fluxo diferente de
desenvolvimento. Por exemplo, integrar a novas
features na master, pois na maioria das vezes,
você deseja que após a integração as duas
branches apontem para o mesmo commit, ou seja,
estejam iguais.

GIT Conceitos
31/01/17 GIT
Your Computer
GIT CHERRY PICK
Local Repository
Remote
Repository
Passa commits específicos de um branch para outra
do mesmo repositório
Branch 1 Branch 2

31/01/17 GIT
GIT CHERRY PICK POR LINHA DE COMANDO
1º - Cria o arquivo ou vários arquivo em um branch e realiza o commit

31/01/17 GIT
2º - Verifica o commit realizado na branch

31/01/17 GIT
3º - Recupera esse commit para outra branch

31/01/17 GIT
GIT CHERRY PICK PELO ECLIPSE
1º - Abre a view history: windows -> show view -> history
2º - Clicar na opção ver commits de todas as branches
3º - Clicar em cima de um commit de outra branch
4º - Utilizar o comando cherry pick...
2º
3º
4º

31/01/17 GIT
RESOLVENDO CONFLITOS NO GIT = FETCH + REBAS
PELO ECLIPSE
1º - Desenvolvedor 1 atualiza o seu repositório
2º - Desenvolvedor 2 atualiza o seu repositório
3º - Desenvolvedor 1 realiza o commit C2 na linha Y da classe X
4º - Desenvolvedor 2 realiza o commit C3 na mesma linha Y da
mesma classe X
5º - Desenvolvedor 1 realizar o push para o remoto
6º - Desenvolvedor 2 tentar realizar o push da sua alteração para
o remoto

Cenário de Conflitos
31/01/17 GIT
Remote Repository
Master
c0 c1
Local Repository
Master
c0 c1
Local Repository
Master
c0 c1
Denv 2Denv 1
PULL
PULL
PELO ECLIPSE

Local Repository
Master
31/01/17 GIT
Remote Repository
Master
c0 c1
Local Repository
Master
c0 c1
c3c0 c1
c2
Denv 2Denv 1
PELO ECLIPSE

31/01/17 GIT
Remote Repository
Master
c0 c1 c2
Local Repository
Master
c0 c1 c2
Local Repository
Master
c0 c1 c3
1º PUSH
Denv 2Denv 1
PELO ECLIPSE

31/01/17 GIT
Remote Repository
Master
c0 c1 c2
Local Repository
Master
c0 c1
Local Repository
Master
c0 c1
c2
1º PUSH
2º PUSH
ERRO!!!
Non fast forward
Denv 1 Denv 2
c3
PELO ECLIPSE

Solução: Fetch + Rebase
31/01/17 GIT
Your Computer
Local Repository
MasterBranch_1
GIT REBASE
c0
c1
c0
c1
c2
c3
5º git rebase branch_1
c2

Nota
31/01/17 GIT
• Uma das desvantagens dos sistemas de controle de
versão distribuídos como o GIT, é que os commits são
feitos nas máquinas locais, fora de ordem
• Então ao enviar para o repositório remoto, o
desenvolvedor precisa sempre se preocupar em manter o
ordem dos commits, o que torna eles mais complexos do
que os controles de versão centralizados como o SVN.

31/01/17 GIT
• Alteração de 4 classes por desenvolvedores
diferentes
PELO ECLIPSE

31/01/17 GIT
• Realiza um Commit Local
PELO ECLIPSE

• Tenta enviar para o repositório Remoto
• Erro ao fazer o push: non Fast Foward!
31/01/17 GIT
PELO ECLIPSE

31/01/17 GIT
• 1º Fetch para recuperar o que foi
modificado no remoto
PELO ECLIPSE

31/01/17 GIT
• Opa, tem um commit novo para recuperar,
o seu commit também ainda não foi
integrado no remoto
PELO ECLIPSE

31/01/17 GIT
• 2º Rebase para aplicar as mudanças ao
seu código
PELO ECLIPSE

31/01/17 GIT
• Rebase parou
porque achou
um conflito
PELO ECLIPSE

31/01/17 GIT
• Corrige o conflito pelo Merge Tool do Eclipse
PELO ECLIPSE

31/01/17 GIT
• Altera o lado esquerdo e salvar o arquivo
PELO ECLIPSE

31/01/17 GIT
• Após a alteração, add to index
PELO ECLIPSE

31/01/17 GIT
• Pronto! Conflito resolvido
PELO ECLIPSE

31/01/17 GIT
• Mas tem outro?! 
PELO ECLIPSE

31/01/17 GIT
• Rebase -> Continue
PELO ECLIPSE

31/01/17 GIT
• Usando a view “git staging area” é possível
ver todas as classes que possuem conflito
• Corrige o próximo, salva e add to index
1º Dois cliques aqui
2º Mostra o conflito
aqui em cima
PELO ECLIPSE

31/01/17 GIT
• “git staging area”
• Opa, resolvi, parece que não tem mais
nenhum.
• Vamos ver ...Continue Rebase
PELO ECLIPSE

31/01/17 GIT
• Rebase Terminou com sucesso, todos os
conflitos resolvidos
PELO ECLIPSE

31/01/17 GIT
• Seu commit tá no topo. Não tem mais nada
para trazer. Podemos realizar um PUSH
PELO ECLIPSE

31/01/17 GIT
• Nada novo para enviar, nada novo para
trazer... Fim.
PELO ECLIPSE

31/01/17 GIT
• Crigando
GIT TAGGING
Your Computer
Local Repository
Marca pontos específicos do histórico como sendo importantes.
Normalmente significa uma versão estável do sistema
C0 C1 C2 C3
V1.0

31/01/17 GIT
• Criar uma tag a partir do último commit
GIT TAGGING PELO ECLIPSE

31/01/17 GIT
• Criar uma tag a partir de um commit
específico

31/01/17 GIT
• Colocar o nome e descrição da tag

31/01/17 GIT
• Enviar uma tag para o remoto
• Apenas criar uma tag localmente não significa
muita coisa, como os commits é preciso fazer o
push da tag para o remoto

31/01/17 GIT
• Enviando uma tag para o remoto

31/01/17 GIT
• Alterando uma tag existente
Caso tenha faltado algo na tag,
é possível sobrescreve uma criada
anteriormente de mesmo nome

31/01/17 GIT
• Removendo uma tag localmente
• Caso a tag criada esteja errada é possível
removê-la.

31/01/17 GIT
• Removendo uma tag remotamente
• Em vez do push tags... usar o push normal
• Team -> Remote -> push

• No campo:
“Remote ref to
delete”
• colocar:
refs/tags/
”nome_da_tag”
31/01/17 GIT
• Removendo uma tag remotamente

Trabalhando com Múltiplos
Repositórios
31/01/17 GIT

Repositórios
31/01/17 GIT
 Git é bastante poderoso. Você pode criar vários fluxos
entre branches de um mesmo repositório, mas também
fluxos entre vários repositórios.
 A figura baixo mostra o fluxo dos repositórios do kenel do
linux.

Repositórios
31/01/17 GIT
Ao realizar o clone de um repositório remoto, o
repositório local mantem referências a apenas esse
repositório
Por padrão chamado de “origin”
É possível adicionar vários repositórios remotos ao
seu repositório local

Repositórios
31/01/17 GIT
Ao adicionar o remoto você deve configura se vai
enviar informações para esse repositório ou
recuperar informações de lá.
Vamos primeiro configurar para enviar (push)

Repositórios
31/01/17 GIT
Adicione a URL desse novo repositório remoto

Repositórios
31/01/17 GIT
 Repositório adicionado estava vazio
 Ao realizar um push para esse novo repositório,
todas as informações do repositório “origin”, que
estavam na sua máquina, são enviadas para o
segundo remoto, “origin2”.

Repositórios
31/01/17 GIT
Ao realizar o
push escolha
o remoto
“origin2”
Que não é o
repositório de
onde o código
foi clonado

Repositórios
31/01/17 GIT
Escolha a
branch remota
do origin2 e
finalize o push

Repositórios
31/01/17 GIT
Realize o
clone desse
segundo
repositório
para a
máquina local

Repositórios
31/01/17 GIT
Veja que os dois repositórios estão iguais
Ou seja, as informações do remoto “origin” foram
enviadas para “origin2”

Repositórios
31/01/17 GIT
A cada nova
informação
adiciona é
possível enviar
para origin e
origin2.

Repositórios
31/01/17 GIT
Ao realizar um push no clone local de origin2,
as tags enviadas estão no novo repositório

Repositórios
31/01/17 GIT
Configurando um segundo repositório para receber
informações. Chamado de “origin2_fetch”

Repositórios
31/01/17 GIT
Escolha qual será o
nome da branch
remota no seu
repositório local
normalmente
refs/remotes/nome_dad
o_ao_remoto

Repositórios
31/01/17 GIT
É criada uma branch remota para o repositório
“origin2_fetch”

Repositórios
31/01/17 GIT
Para receber as atualizações do repositório
origin2_fetch: Remote -> fetch... -> Escolha o
“origin2_fetch”
As mudanças são jogadas nas
branches remotas do repositório
“origin2_fetch”.
É possível pegar as
atualizações do origin2_fetch e
realizar um push para o origin, o
repositório de onde você
clonou.

GIT Workflows
• O GIT permite criar vários
fluxos de desenvolvimento que
atendam a dinâmica da suas
empresa.
• Pode-se ter uma branch de
aprimoramento, uma branch
para manutenção, uma branch
que congele o código a ser
homologado antes de ir para
produção, enquanto novas
tarefas para a próxima release
já podem começar a serem
feitas, etc...
31/01/17 GIT

Features Branch Workflow
31/01/17 GIT

• A ideia central é que cada tarefa/feature seja
desenvolvida na sua própria branch
• Cada desenvolvedor pode trabalhar na sua
feature sem impactar nos demais
desenvolvedores
• A branch master nunca terá código quebrado
31/01/17 GIT

• Feature Branch Workflow para branches locais
• A branch master local fica recebendo apenas
atualizações do remoto, nenhum commit é realizado
diretamente nela
• Todo commit e push para o remoto é realizado a partir
de uma branch própria.
31/01/17 GIT

• A branch master local deve ser read only e
receber apenas pull do do remoto
• Isso evita que por algum problema, a sua branch
master local fique “quebrada” com conflitos que irão
dificultar o seu desenvolvimento.
• Estimula refactory e experiências durante o
desenvolvimento. No pior caso, se não der certo,
você apaga a branch e começa tudo de novo a partir
da master.
• Facilita a atualização branch master, pois nela nunca
haverá conflitos e pode-se sempre realizar “pulls”
diretamente
31/01/17 GIT

31/01/17 GIT
FLUXO PARA BRANCHES LOCAIS
Local Repository
1o PULL
MasterBranch_1
2º Create Branch

31/01/17 GIT
Local Repository
MasterBranch_1
4o PUSH3º Commit

31/01/17 GIT
Local Repository
5o PULL
MasterBranch_1
6º Delete Branch

GitHub Workflow
31/01/17 GIT
• GitHub Workflow
• Fluxo criado para projetos open source que não
possuem releases bem definidas
• Princípios:
1. Tudo que estiver na branch master pode ser colocado em
produção
2. Crie uma branch local nova para tarefa e periodicamente
faça push para uma branch de mesmo nome no servidor
3. Quando a tarefa estiver terminada, solicite um Pull
Request para a branch master
4. Quando o responsável revisar/aprovar o pull request,
faça merge com a master
5. Uma vez na master, pode ser colocado em produção
imediatamente

GitHub Workflow
31/01/17 GIT
Local Repository
MasterBranch_1
1º Create Branch
Remote Repository
Master

GitHub Workflow
31/01/17 GIT
Local Repository
MasterBranch_1
2º Push para um branch remota de mesmo nome
Remote Repository
MasterBranch_1
forbidden
protected

GitHub Workflow
31/01/17 GIT
Local Repository
MasterBranch_1
3º Crie um PULL Request da branch remota para a master
Remote Repository
MasterBranch_1
pull request

GitHub Workflow
31/01/17 GIT
Local Repository
MasterBranch_1
4º Alguém revisa/aprova o Pull Request
5º Remova a branch local e remota
6º Atualize a master local
7º Volte ao 1º passo
Remote Repository
MasterBranch_1
PULL

Gitflow Workflow
• Define um conjunto de restrito de branch remotas
concebido em torno das releases do projeto
• Indicado para projetos grandes que possuem
datas de releases bem definidas
• Atribui funções muito específicas para diferentes
branches e define como e quando elas devem
interagir
31/01/17 GIT

Gitflow Workflow
• Possui 2 branches principais
• A branch master armazena o histórico lançamento
oficial, refletindo o código de produção.
• A branch develop serve como uma branch para
integração de features, sempre reflete um estado com
as últimas alterações de desenvolvimento entregues
para a próxima release
• Essas duas branch tem vida infinita, ou seja, nunca são
removidas
31/01/17 GIT

Gitflow Workflow
• Além das duas branches principais existem
outras branches com um tempo de vida definido
• Feature Branches: Usadas para desenvolver novas
feature/tarefas, para as próximas releases ou releases
distantes. Existe enquanto a feature está sendo
desenvolvida e será integrada a branch develop ou
descartada. ( Feature Branch normalmente são locais,
apenas no repositório do desenvolvedor, eventualmente
pode ser enviadas para o remoto para fim de backup)
31/01/17 GIT

Gitflow Workflow
• Release branches: Devem ser criadas a partir da branch
develop e serem integradas novamente na develop e
master, normalmente possua o nome release-x.y.z, onde
x.y.z é o número da versão.
• São usadas para preparar a release. Fazendo as
pequenas correções finais antes de lançar a versão de
produção. Com isso a feature develop fica livre para
receber mudanças da próxima grande release
31/01/17 GIT

Gitflow Workflow
• Hotfix branches: São parecidas com as releases
branches, preparam para uma nova release do sistema,
embora não planejadas
• Devem ser criada a partir da master e serem integradas
na branches master e develop
• São usadas para correções de erros ou tarefas urgentes
que não podem esperar o ciclo normal de
desenvolvimento
31/01/17 GIT

Gitflow Workflow
31/01/17 GIT
master
1.0
Início do Processo

Gitflow Workflow
31/01/17 GIT
master
develop
feature
1.0
Desenvolvimento de uma nova feature
Repositório Local

feature
Gitflow Workflow
31/01/17 GIT
master
develop
1.0
Desenvolvimento de uma nova feature
Repositório Local

feature
Gitflow Workflow
31/01/17 GIT
master
develop
1.0
Desenvolvimento da feature finalizado
Repositório Local

feature
Gitflow Workflow
31/01/17 GIT
master
hotfix-1.1
develop
1.0
Surgimento de um bug em produção
Repositório Local

feature
hotfix-1.1
Gitflow Workflow
31/01/17 GIT
master
develop
1.0
Finalizando um bug urgente em produção
1.1
Repositório Local

feature
hotfix-1.1
Gitflow Workflow
31/01/17 GIT
master
release-2.0
develop
1.0
Preparando o lançamento de uma versão, congela o código da build
1.1
RC1
Repositório Local

feature
hotfix-1.1
release-2.0
Gitflow Workflow
31/01/17 GIT
master
develop
1.0
Tarefas da próxima release começam a serem desenvolvidas
1.1
RC1
Repositório Local

feature
hotfix-1.1
release-2.0
Gitflow Workflow
31/01/17 GIT
master
develop
1.0
Lançamento de versões release candidate
1.1
RC1 RC2
Repositório Local

feature
hotfix-1.1
release-2.0
Gitflow Workflow
31/01/17 GIT
master
develop
1.0
Versão do Sistema foi Finalizada, novo ciclo se inicia
1.1
RC1 RC2
2.0
Repositório Local

Gitflow Workflow na Prática
• Uma possível maneira de implementar esse fluxo
utilizando o EGit
• Vamos criar 3 três branches com nomes diferentes do
padrão apenas para simular o fluxo pelo eclipse
• master_teste: A master do projeto que contém a versão estável do
sistema
• develop_teste: A branch de aprimoramentos da próxima release,
criada a partir da master_teste
• hotfix_teste: A branch de erros, criada a partir da master_teste
31/01/17 GIT

• No começo do fluxo, todas as branches apontam para o
mesmo ponto (mesmo commit).
• Ps.: No final do fluxo, todas devem continuar apontando
para o mesmo commit.
31/01/17 GIT

• Fluxo de desenvolvimento da próxima release se inicia.
Commits são feito na branch develop_teste que começa
a se distanciar na master_teste como os novos commits
31/01/17 GIT

• Surge uma tarefa de erro.
• Um novo commit é realizado para a branch hotfix_teste
31/01/17 GIT

• Agora é preciso finalizar a branch hotfix_teste, ou seja,
integra-la na master_teste para a correção do erro ir
para produção, gerando uma nova versão do sistema.
• Faça checkout da branch master_teste e utilize a
operação de merge.
31/01/17 GIT

• As branches master_teste e hotfix_teste estão iguais
agora. Marque uma tag estável na master_teste e envie
o código da master_teste para produção.
31/01/17 GIT

• Ainda falta integrar o código da hotfix_teste na
develop_teste
• Faça checkout para a develop_teste e aplique o merge
da hotfix_teste -> develop_teste
31/01/17 GIT

• Como a develop_teste evoluiu, podem haver conflitos.
Se isso ocorrer, é mostrado o commit em conflito, peça o
responsável que realize a correção do conflito na branch
develop_teste
• O gestor de configuração e mudança não deve ser o
responsável por solucionar o conflito e sim o
desenvolvedor que alterou o código.
31/01/17 GIT

• Realize um hard reset na branch develop_teste para
desfazer as mudanças aplicadas pelo merge que estava
com conflito e aguarde o desenvolvedor solucioná-lo.
31/01/17 GIT

• Após o desenvolvedor corrigir o conflito, aplique o merge
da hotfix_teste -> develop_teste novamente
• A aplicação do merge deve ser direta. Sem precisar de
alterações manuais.
• Isso finaliza a branch hotfix.
• Os commits realizados na hotfix foram integrados à master para ir
para produção e foram integrados à develop para não serem
perdidos quando a develp for integrada à master futuramente
31/01/17 GIT

• A integração dos commits de uma branch para outra
branch deve ser feita pelo gerente de configuração e
mudança aplicando esses merges. Não deve ser feita
pelo desenvolvedor.
• É responsabilidade do gestor de configuração e mudança
garantir que os commits aplicados na hotfix foram
integrados na master e na develop
31/01/17 GIT

• Depois de realizar todos os aprimoramentos planejados,
está na hora de finalizar a branch develop_teste,
aplicando as mudanças na master_teste.
• Como desde o começo do fluxo a master_teste só pode
ter evoluído o que existia na hotfix_teste e os possíveis
conflitos da hotfix_teste já foram solucionados quando
foram aplicado na develop_teste, no merge entre
develop_teste -> master_teste não deve haver conflitos
31/01/17 GIT

• Faça checkout da master_teste e realize o merge
develop_teste -> master_teste
• Crie uma nova tag na master_teste e mande o código
para produção
31/01/17 GIT

• Isso finaliza o fluxo da develop_teste
• As branches master_teste e develop_teste devem estar
iguais agora
• A hotfix_teste não está igual as demais branches, mas
como finalizou o fluxo da develop_teste, a hotfix_teste
deve ser apagada e criada a partir da master_teste
novamente. Deixando as 3 branches iguais para o início
de um novo ciclo no fluxo.
31/01/17 GIT

• Assim ao iniciar um novo ciclo as 3 branches estão no
mesmo ponto, como no início do ciclo anterior.
• A branch release é semelhante à hotfix, lembrando que
quando é criada a release, a hotfix não deve ser usada
• Lembrar também que a hotfix e release são criadas a
cada ciclo e seus nomes devem conter a versão a que
elas se referem. Exemplo: hotfix-1.1 e release-2.0
31/01/17 GIT

GitLab – Interface para o seu repositório GIT
31/01/17 GIT

31/01/17 GIT
• GitLab inclui entre as suas
funcionalidades:
• gerenciamento de repositórios GIT
• code reviews
• issue tracking
• wikis
• Pontos fortes:
• Interface rica e intuitiva
• Pontos fracos:
• Instalação ainda um pouco complicada

Revisão de Código com o GitLab
31/01/17 GIT
• GitLab permite que membros da equipe revisem
o código de outros membros antes das
alterações serem aprovadas para uma release
do sistema
• Muito último quando se tem estagiários ou
pessoas novas na equipe
• Para isso o GitLab faz uso da operação de
Merge Request, similar a operação de PULL
Request do GitHub workflow

31/01/17 GIT
• Para forçar a criação de Merge Request,
desabilite o PUSH para a branch que contém as
releases do sistema (normalmente a master)
• Project -> Settings

31/01/17 GIT
• Project -> Settings -> Protected Branches

31/01/17 GIT
• Escolha a Branch e clique em PROTECT

Merge Resquest no GitLab
Realizando push para feature branch remota

Crie um Merge Request para a branch que a
modificação deve ser enviada

Escolha da branch onde você realizou a mudança
para a branch desejada (normalmente a master)

Defina quem revisará o merge request e submeta

Visualize na tela inicial os Merge Requests feitos
para você

Existe várias opções no momento de revisar o
merge request
 É possível visualizar as alterações realizadas
 Iniciar uma Discussão com quem solicitou o merge
 etc..

Por fim, aceite o merge request e remova a
branch remota criada

GIT Documentação
31/01/17 GIT
Git - guia prático:
http://rogerdudler.github.io/git-guide/
index.pt_BR.html
Git iniciando:
http://git-scm.com/book/en/v2/
Git-Basics-Getting-a-Git-Repository
Git – documentação completa:
http://git-scm.com/doc

EGIT Documentação
31/01/17 GIT
EGit – User Guide:
https://wiki.eclipse.org/EGit/User_Guide

GIT Workflows
31/01/17 GIT
Comparing Workflows:
https://www.atlassian.com/git/tutorials/compari
ng-workflows
A successful Git branching model
http://nvie.com/posts/a-successful-git-
branching-model/

31/01/17 GIT
Sobre o GitLab:
https://about.gitlab.com/
Instalação
https://about.gitlab.com/installation/
Repositório GitLab online:
https://about.gitlab.com/gitlab-com/

Figuras Retiradas de:
31/01/17 GIT
https://www.qnap.com/i/useng/app_center/con_show.php?op=showone&i
nternalName=git&version=2.1.0&down_1_name=TS-
NASX86&jump_win=1
http://programmers.stackexchange.com/questions/35074/im-a-
subversion-geek-why-should-i-consider-or-not-consider-mercurial-or-git-or
http://stackoverflow.com/questions/2621610/what-git-branching-models-
work-for-you

GIT31/01/17
jadsonjs@gmail.com

GIT guia completo

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a GIT guia completo

Semelhante a GIT guia completo (20)

Mais de Jadson Santos

Mais de Jadson Santos (19)

GIT guia completo