Разница между git pull и git pull --rebase

Я начал использовать git некоторое время назад и не полностью разобрался в тонкостях. Мой основной вопрос здесь заключается в том, чтобы узнать разницу между a git pull и git pull --rebase с добавлением --rebase опция, похоже, не делает что-то совсем другое : просто тянет.

пожалуйста, помогите мне понять разницу.

5 ответов


git pull = git fetch + git merge против отслеживания ветки вверх по течению

git pull --rebase = git fetch + git rebase против отслеживания ветки вверх по течению

если вы хотите знать, как git merge и git rebase отличаться, читать это.


иногда у нас есть восходящий поток, который перемотал / перемотал ветку, от которой мы зависим. Это может быть большой проблемой-вызвать беспорядочные конфликты для нас, если мы будем ниже по течению.

магия git pull --rebase

нормальный git pull, грубо говоря, что-то вроде этого (мы будем использовать удаленный origin и ветку под названием foo во всех этих примерах):

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

на первый взгляд, вы можете подумать, что git pull --rebase просто это:

git fetch origin
git rebase origin/foo

но это не поможет, если восходящая ребаза включала какое-либо" раздавливание " (что означает, что идентификаторы патчей коммитов изменились, а не только их порядок).

что означает, что git pull --rebase должен сделать немного больше. Вот объяснение того, что он делает и как.

Предположим, ваша отправная точка такова:

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

проходит время, и вы сделали некоторые коммиты поверх своих собственных "foo":

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

git тянуть в этот момент приведет к хаосу. Даже git fetch; git rebase origin / foo не сократил бы его, потому что фиксации "b" и "c" с одной стороны и фиксация "b+c" с другой будут конфликтовать. (И аналогично с d, e и d+e).

что git pull --rebase делает, в данном случае, это:

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

это дает вам:

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

вы все равно можете получить конфликты, но они будут подлинными конфликтами (между p/q/r и a/b+c/d+e/f), а не конфликтами, вызванными конфликтом b/C с b+c и т. д.

ответ взят из (и слегка изменен):
http://gitolite.com/git-pull--rebase


Предположим, у вас есть два коммита в местное отделение:

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

после "git pull", будет:

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

после "git pull --rebase" не будет точки слияния G. обратите внимание, что D и E становятся разными фиксациями:

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

в самом простом случае без столкновения

  • С rebase: rebases ваши локальные коммиты на вершине удаленной головы и делает не создать слияние / merge commit
  • без / normal: слияние и создание фиксации слияния

Читайте также:

man git-pull

точнее, git pull запускает git fetch с заданными параметрами и вызывает git merge для объединения извлеченных головок ветвей в текущий отделение. С --rebase он запускает git rebase вместо git merge.

Читайте также:
когда я должен использовать git pull --rebase?
http://git-scm.com/book/en/Git-Branching-Rebasing


для этого важно понять разницу между Merge и Rebase.

Rebases - это то, как изменения должны проходить сверху иерархии вниз а слияния-это то, как они текут вверх.

для деталей см. -http://www.derekgourlay.com/archives/428