Diferença entre git pull e git pull --rebase

Comecei a usar o git há algum tempo e não entendo completamente os meandros. Minha pergunta básica aqui é descobrir a diferença entre a git pulle git pull --rebase, já que adicionar a --rebaseopção não parece fazer algo muito diferente: apenas dá um puxão.

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

git pull= git fetch+ git mergecontra rastreamento da filial a montante

git pull --rebase= git fetch+ git rebasecontra rastreamento da filial a montante

Se você quiser saber como git mergee git rebasediferir, leia isto .

Às vezes, temos um upstream que reformulou / rebobinou um ramo em que estamos dependendo. Isso pode ser um grande problema - causando conflitos confusos para nós, se estivermos no downstream.

A mágica é git pull --rebase

Um pull normal do git é, de maneira geral, algo assim (usaremos um remoto 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 a reorganização upstream envolver qualquer "esmagamento" (o que significa que os IDs de patch dos commits mudaram, não apenas a ordem deles).

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

Digamos que seu ponto de partida é este:

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

O tempo passa e você fez alguns commit 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 do montante não apenas rebateu seu "foo", mas também usou uma ou duas abóboras. Sua cadeia de commit agora se parece com isso:

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

Um puxão do git nesse ponto resultaria em caos. Até um git buscado; O git rebase origin / foo não o eliminaria, pois confirma "b" e "c" de um lado e confirma "b + c" do outro. (E da mesma forma com d, e, e d + e).

O git pull --rebaseque, neste caso, é:

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

Isso lhe dá:

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

Você ainda pode ter 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 (e ligeiramente modificada):
http://gitolite.com/git-pull--rebase

Suponha que você tenha duas confirmações na ramificação local:

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

Após "git pull", será:

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

Após "git pull --rebase", não haverá ponto de mesclagem G. Observe que D e E se tornam diferentes commits:

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

No caso mais simples, sem colisões

• com rebase: repassa seu local confirma o ontop do HEAD remoto e não cria um commit de mesclagem / mesclagem
• sem / normal: mescla e cria uma confirmação de mesclagem

Veja também:

man git-pull

Mais precisamente, o git pull executa o git fetch com os parâmetros fornecidos e chama o git merge para mesclar as cabeças de ramificação recuperadas na ramificação atual. Com --rebase, ele executa git rebase em vez de 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 mesclas são como elas fluem de volta para cima.

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