Diferença entre git pull e git pull –rebase

Eu comecei a usar o git em algum momento e não entendo completamente os meandros. Minha pergunta básica aqui é descobrir a diferença entre um git pull e git pull --rebase , já que adicionar a opção --rebase não parece fazer algo muito diferente: apenas faz um pull.

Por favor, ajude-me a entender a diferença.

git pull = git fetch + git merge contra rastreamento ramo upstream

git pull --rebase = git fetch + git rebase contra rastreamento de filial upstream

Se você quiser saber como o git merge e git rebase diferem, leia isto .

Às vezes temos um upstream que rebased / rewound um ramo que estamos dependendo. Isso pode ser um grande problema – causar conflitos confusos para nós se estivermos downstream.

A magia é git pull --rebase

Um git pull normal é, vagamente falando, algo assim (usaremos um remote chamado origin e um branch chamado foo em todos esses exemplos):

 # assume current checked out branch is "foo" git fetch origin git merge origin/foo 

À primeira vista, você pode pensar que um git pull –rebase faz exatamente isso:

 git fetch origin git rebase origin/foo 

Mas isso não ajudará se o rebase upstream envolver qualquer “squashing” (significando que os patch-ids dos commits mudaram, não apenas sua ordem).

O que significa git pull –rebase tem que fazer um pouco mais que isso. Aqui está uma explicação do que faz e como.

Digamos que seu ponto de partida seja este:

 a---b---c---d---e (origin/foo) (also your local "foo") 

O tempo passa e você fez alguns commits em cima do seu próprio “foo”:

 a---b---c---d---e---p---q---r (foo) 

Enquanto isso, em um ataque de raiva anti-social, o mantenedor de upstream não apenas rebateu seu “foo”, ele até usou uma ou duas abóboras. Sua cadeia de commits agora se parece com isso:

 a---b+c---d+e---f (origin/foo) 

Um puxão nesse ponto resultaria em caos. Até mesmo um git fetch; git rebase origin / foo não iria cortá-lo, porque comete “b” e “c” de um lado, e cometer “b + c” do outro, entraria em conflito. (E similarmente com d, e e d + e).

O que git pull --rebase , neste caso, é:

 git fetch origin git rebase --onto origin/foo e foo 

Isso te dá:

  a---b+c---d+e---f---p'---q'---r' (foo) 

Você ainda pode receber conflitos, mas eles serão conflitos genuínos (entre p / q / r e a / b + c / d + e / f), e não conflitos causados ​​por b / c em conflito com b + c, etc.

Resposta retirada de (e ligeiramente modificada):
http://gitolite.com/git-pull–rebase

Suponha que você tenha dois commits no branch local:

  D---E master / A---B---C---F origin/master 

Depois de “git pull”, será:

  D--------E / \ A---B---C---F----G master, origin/master 

Depois de “git pull –rebase”, não haverá ponto de mesclagem G. Note que D e E se tornam commits diferentes:

 A---B---C---F---D'---E' master, origin/master 

No caso mais simples de não colisões

  • com rebase: rebase seus commits locais ontop do HEAD remoto e não cria um commit de merge / merge
  • sem / normal: mescla e cria um commit de mesclagem

Veja também:

man git-pull

Mais precisamente, git pull executa git fetch com os parâmetros fornecidos e chama git merge para mesclar os headers recuperados na ramificação atual. Com o –rebase, ele executa o git rebase em vez do git merge.

Veja também:
Quando devo usar o git pull –rebase?
http://git-scm.com/book/en/Git-Branching-Rebasing

Para isso é importante entender a diferença entre Mesclar e Rebase.

Rebases são como as mudanças devem passar do topo da hierarquia para baixo e as fusões são como elas retornam para cima.

Para detalhes consulte – http://www.derekgourlay.com/archives/428