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

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

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

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 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

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

• with rebase: перебазирует ваши локальные коммиты поверх удаленного HEAD и не создает коммит слияния / слияния
• без / 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.

Обоснование - это то, как изменения должны проходить от вершины иерархии вниз, а слияния - то, как они возвращаются вверх.

За подробностями обращайтесь - http://www.derekgourlay.com/archives/428