Différence entre git pull et git pull --rebase

J'ai commencé à utiliser git il y a quelque temps et je ne comprends pas bien les subtilités. Ma question fondamentale ici est de découvrir la différence entre a git pullet git pull --rebase, car l'ajout de l' --rebaseoption ne semble pas faire quelque chose de très différent: fait juste un pull.

Veuillez m'aider à comprendre la différence.

git pull= git fetch+ git mergecontre le suivi de la branche amont

git pull --rebase= git fetch+ git rebasecontre le suivi de la branche amont

Si vous voulez savoir comment git mergeet git rebasedifférez, lire .

Parfois, nous avons un amont qui a rebasé / rembobiné une branche dont nous dépendons. Cela peut être un gros problème - provoquant des conflits désordonnés pour nous si nous sommes en aval.

La magie est git pull --rebase

Un git pull normal est, en gros, quelque chose comme ça (nous utiliserons une télécommande appelée origine et une branche appelée foo dans tous ces exemples):

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

À première vue, vous pourriez penser qu'un git pull --rebase fait exactement cela:

git fetch origin
git rebase origin/foo

Mais cela n'aidera pas si le rebase en amont impliquait un "écrasement" (ce qui signifie que les patch-id des commits ont changé, pas seulement leur ordre).

Ce qui signifie que git pull --rebase doit faire un peu plus que cela. Voici une explication de ce qu'il fait et comment.

Disons que votre point de départ est le suivant:

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

Le temps passe et vous avez fait quelques commits en plus de votre propre "foo":

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

Pendant ce temps, dans une crise de rage antisociale, le mainteneur en amont a non seulement rebasé son "foo", il a même utilisé une ou deux courges. Sa chaîne de validation ressemble maintenant à ceci:

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

Un git pull à ce stade entraînerait le chaos. Même un git fetch; git rebase origin / foo ne le couperait pas, car les commits "b" et "c" d'un côté, et le commit "b + c" de l'autre, seraient en conflit. (Et de même avec d, e et d + e).

Qu'est git pull --rebase- ce que, dans ce cas, c'est:

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

Cela vous donne:

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

Vous pouvez toujours avoir des conflits, mais ce seront de véritables conflits (entre p / q / r et a / b + c / d + e / f), et non des conflits causés par b / c en conflit avec b + c, etc.

Réponse tirée de (et légèrement modifiée):
http://gitolite.com/git-pull--rebase

Supposons que vous ayez deux validations dans la branche locale:

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

Après "git pull", ce sera:

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

Après "git pull --rebase", il n'y aura plus de point de fusion G. Notez que D et E deviennent des commits différents:

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

Dans le cas le plus simple d'absence de collision

• avec rebase: rebase vos validations locales sur le dessus de HEAD distant et ne crée pas de fusion / validation de fusion
• sans / normal: fusionne et crée un commit de fusion

Voir également:

man git-pull

Plus précisément, git pull exécute git fetch avec les paramètres donnés et appelle git merge pour fusionner les têtes de branche récupérées dans la branche actuelle. Avec --rebase, il exécute git rebase au lieu de git merge.

Voir aussi:
Quand dois-je utiliser git pull --rebase?
http://git-scm.com/book/en/Git-Branching-Rebasing

Pour cela, il est important de comprendre la différence entre fusionner et rebaser.

Les rebases sont la façon dont les changements doivent passer du haut de la hiérarchie vers le bas et les fusions sont la façon dont ils remontent.

Pour plus de détails, consultez - http://www.derekgourlay.com/archives/428