Git Merge e Git Rebase

The first thing to know is thatgit rebase and git merge

solves the same problem!

Integrate changes from one branch into another branch

They just do it in very different ways.

git merge

1 2 5 6

3 4

master

feature

1 2 5 6

3 4

master

git checkout master

feature

head

1 2 5 6

3 4

master

git checkout mastergit merge feature

feature

7

head

Merge

Merge é um novo commit. A principal diferença é que ele tem dois pais. Todos os outros commits tem apenas um pai. 1 2 5 6

3 4

git checkout mastergit merge feature

feature

7

master head

mergefast forward

1 2

3 4

master

feature

1 2

3 4

master

feature

git checkout master

head

Merge Fast Forward

O único momento que o merge não cria um novo commit é no merge fast forward.

1 2

3 4

master

feature

git checkout mastergit merge master

head

git merge é legal por ser uma operação não destrutiva. As branchs existentes não são alteradas de forma alguma. Isso evita armadilhas potenciais causadas pelo git rebase.

Por outro lado, isso também significa que a branch terá um commit de merge toda vez que for necessário incorporar alterações de outra branch (master por exemplo).

Se master é muito ativo, isso pode poluir um pouco o histórico de commits.

git rebase

1 2 5 6

3 4

master

feature

1 2 5 6

3 4

master

git checkout feature

feature head

1 2 5 6

7

master

git checkout featuregit rebase master

feature head

(3)

1 2 5 6

7

master

git checkout featuregit rebase master

feature head

(3) (4)

8

1 2 5 6

7

master

git checkout featuregit rebase master

feature head

(3) (4)

8

RebaseRecria os commits de uma branch no topo da outra. Repare que são criados novos commits.

O principal benefício do git rebase é que você obtém um histórico do projeto muito mais limpo.

Primeiro, ele elimina os commits de merge desnecessários exigidos pelo git merge. Segundo, git rebase resulta em um histórico perfeitamente linear. Isso facilita a navegação no seu projeto com comandos como git log, git bissect e gitk.

Mas, reescrever o histórico de commits pode ser potencialmente catastrófico para seu fluxo de trabalho de colaboração.

Basicamente, como regra de ouro, não use git rebase em branchs compartilhadas.

legal, mas e aí?!

Cenário com merge

1 2 5 6

3 4

master

feature

1 2 5 6

3 4 7 8

bug_fixfeature

master

1 2 5 6

3 4

master

7 8

bug_fixfeature

git checkout master

head

1 2 5 6

3 4

master

7 8

9

bug_fixfeature

git checkout mastergit merge bug_fix

head

1 2 5 6

3 4

master

7 8

9

bug_fixfeature

x x

1 2 5 6

3 4

master

7 8

9

bug_fixfeature

x x

git checkout master

head

1 2 5 6

3 4

master

7 8

9

bug_fixfeature

x x

git checkout mastergit merge feature

y

head

Mesmo cenário + rebase

1 2 5 6

3 4

master

feature

1 2 5 6

3 4 7 8

bug_fixfeature

master

1 2 5 6

3 4

master

7 8

bug_fixfeature

git checkout master

head

1 2 5 6

3 4

master

7 8

9

bug_fixfeature

git checkout mastergit merge bug_fix

head

1 2 5 6

3 4

master

7 8

9

bug_fixfeature

x x

1 2 5 6

3 4

master

7 8

9

bug_fixfeature

x x

git checkout feature

head

1 2 5 6

3 47 8

9

bug_fix feature

x x

git checkout featuregit rebase master

master

head

1 2 5 6

3 47 8

9

bug_fix feature

x x

git checkout master

master

head

1 2 5 6

3 47 8

9

bug_fix feature

x x

git checkout mastergit merge feature

master

head

y

Não manjo nada, colei daqui:● Mergin vs Rebasing by Atlasin● Five Agency Git Merge and Rebase simple explanation

Thanks! ;)