Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Estratégias e Ramificações com Git

No description
by

Marcio Rosner

on 11 March 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Estratégias e Ramificações com Git

Estratégias e Ramificações com Git
Estratégias de ramificações
Manutenção caótica (organização imatura)
Estratégias de ramificações
Objetivos de uma estratégia de ramificação:
MÁRCIO ROSNER
Desenvolvimento em paralelo

Isolamento entre desenvolvedores e equipes
customização para diferentes clientes ou plataformas
outros...
Relembrando Merge x Rebase
Comparando as operações Merge x Rebase:
ramo principal com evoluções e correções
impossível separar correção de evolução
usuários de uma versão recebem nova funcionalidade junto com correção
Estratégias de ramificações
Manutenção em série
ramo principal com evoluções
ramos auxiliares com correções
foco em cliente único
Estratégias de ramificações
Uma branch por feature
ramo principal para integração
ramos auxiliares com features
permite a identificação de cada feature
possibilita a remoção de uma feature
trabalho em paralelo e independente
Obs.: integração deve ser frequente
funcionalidade, correção de bug, tarefa, história ou qualquer segmento de trabalho.
agrupa o trabalho a ser feito de forma funcional
permite o desacoplamento das features
builds e testes independentes: um commit de um desenvolvedor não quebra o trabalho do outro
tem vários commits
toda a feature é integrada, e não commits individuais.
cada feature pode gerar uma release para produção
Integrando com Rebase
Criando 1 branch:
Relembrando com merge:
$ git checkout experiment
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: added staged command
Com rebase:
Agora é possível fazer merge fast-foward no master:
Outro exemplo:
$ git rebase --onto master server client
Obs.: Em caso de conflito use o git diff para localizá-los
Conclusão:
Merge comum:
sua mensagem de commit
Mensagem: "Merge branch <outraBranch>"
(pode dar conflito ao fazer o merge)
C1
C2
C3
C4
Com rebase:
sua mensagem de commit
C1
C2
C3'
sua mensagem de commit
C1
C2
C3'
Agora o merge:
Aplicando um commit em outra branch
git cherry-pick
Melhor opção quando as branchs divergem (e o merge não interessa)
git cherry-pick <hash do commit>
: cria um novo commit
git cherry-pick -n <hash do commit>
: não cria um novo commit
git cherry-pick -x <hash do commit>
: cria o commit com uma msg indicando de onde a mudança original veio
git cherry-pick C D E
Resolvendo Conflitos
identificando o conflito
resolvendo o conflito manualmente:
$git commit -am "conflito resolvido"
vendo o conteúdo do arquivo com conflito
resolvendo o conflito graficamente:
$git mergetool"
Sugestão: instale o KDiff3 e altere o .gitconfig para
escolha uma versão para sobrescrever o conflito:
$git checkout --theirs (--ours) -- teste.txt
Estratégias de merge
Para git merge e git pull:
git <merge/pull> -s <estratégia> -X<opção da estratégia>
Estratégia "resolve":
resolve apenas 2 heads (a branch atual e de onde foi feito o pull) usando o algoritmo 3-way merge.
Estratégia "recursive":
resolve apenas 2 heads usando o algoritmo 3-way merge. Quando tem mais de um ancestral, faz um merge dos ancestrais e usa o resultado com o referência para o 3-way merge. Detecta "renames". É a estratégia default. Tem as seguintes opções:
Theirs
- ao contrário da Ours.
Ours
- resolve os conflitos em "favor" da "nossa" versão.
... mais 9 opções:
https://github.com/git/git/blob/master/Documentation/merge-strategies.txt
Estratégias de merge
Estratégia Octopus
resolve casos com mais de 2 heads (exceto conflitos que exija resolução manual). É o default para pull e merge com mais de 1 branch (atual + 2).
Estratégia Ours:
Resolve qualquer quantiadade de heads, considerando sempre como resultado a head atual, isto é, ignorando as mudanças de todas as outras branches. (Diferente da opção ours da estratégia recursive).
Estratégias de merge
Estratégia Subtree
Esta é uma modificação da estratégia "recursive": Quando tenta fazer o merge de duas árvores A e B, se B é uma sub-árvore de A, B primeiramente é ajustado para ter a mesma estrutura de A, ao invés de ler as duas árvores no mesmo nível. Esse mesmo ajuste é feito na árvore ancestral em comum.
Mudando o histórico
$git rebase -i HEAD~N ou <commit>
- Permite editar/excluir/trocar os últimos N commits:
Obs.: Não inclua nenhum commit que você já enviou a um servidor central — fazer isso irá confudir outros desenvolvedores fornecendo uma versão alternativa da mesma alteração
p, pick = use commit
r, reword = use commit, but edit the commit message
e, edit = use commit, but stop for amending
s, squash = use commit, but meld into previous commit
f, fixup = like "squash", but discard this commit's log message
x, exec = run command (the rest of the line) using shell
Efeito máquina do tempo
Eliminando o commit "D":
Juntando os commits "C" e "D":
A -> B -> C (origin/master)
A -> B -> C -> D -> E -> F (master)
$ git checkout -b bugfix B
A -> B -> C -> D -> E -> F (master)
\
(bugfix)
A -> B -> C -> D -> E -> F (master)
\
B' (bugfix)
git commit --amend -am "mensagem":
$ git rebase bugfix master
A -> B' -> C' -> D' -> E' -> F' (master)
$ git pull --strategy=ours
A -> B -> C -> B' -> C' -> D' -> E' -> F' (master)
Full transcript