git pull --rebase - PullRequest
Новая
       1

git pull --rebase

9 голосов
/ 02 мая 2011

Стартовая ситуация (без внесенных изменений, > указывает текущую ветвь): 

o C [> master][origin/master]
|
o B
|
o A
|
...

После git fetch структура журнала часто выглядит как 

o E [origin/master]
|
o C'
|
o B'
|
o D
|
| o C [>master]
| |
| o B
|/
o A
|
...

Теперь git rebase origin/master master часто вызывает конфликты. git pull --rebase умнее и просто использует git reset, чтобы master также указывал на E, если master == origin/master изначально?

Ответы [ 3 ]

18 голосов
/ 07 октября 2011

Вы можете использовать команду rebase вместо слияния - так работает моя команда, и она работает достаточно хорошо.

Из " Несколько советов по git, которые вы не знали о ":

Поскольку слияния веток в git записываются с фиксацией слияния, предполагается, что они имеют смысл - например, чтобы указать, когда функция была объединена с веткой выпуска.Однако во время регулярного ежедневного рабочего процесса, когда несколько членов команды часто синхронизируют одну ветку, временная шкала загрязняется ненужными микро-слияниями при обычном git pull.Перебазирование гарантирует, что коммиты всегда повторно применяются, так что история остается линейной.

Вы можете настроить определенные ветви, чтобы всегда делать это без флага --rebase:

#make 'git pull' on master always use rebase$ git config branch.master.rebase true

Вы также можете настроить глобальную опцию для установки последнего свойства для каждой новой отслеживаемой ветви:

# setup rebase for every tracking branch$ git config --global branch.autosetuprebase always

16 голосов
/ 18 июля 2012

git pull --rebase равно НЕ так же, как git fetch; git rebase. К сожалению, справочная страница git-pull довольно загадочна из-за разницы: 

   --rebase
       Rebase the current branch on top of the upstream branch
       after fetching. If there is a remote-tracking branch
       corresponding to the upstream branch and the upstream branch
       was rebased since last fetched, the rebase uses that
       information to avoid rebasing non-local changes.

Оказывается, что различие не включает git reset, как и предполагал оригинальный плакат, - на самом деле оно включает reflog (см. здесь , если вы не сталкивались с этим срок до).

Для полной истории о дополнительной магии в git pull --rebase см. Этот ответ:

https://stackoverflow.com/a/11531502/179332

7 голосов
/ 02 мая 2011

git pull --rebase аналогично тому, что будет делать следующее: 

git fetch
git rebase

Таким образом, в вашем случае он покинет хранилище следующим образом: 

o C [> master]
|
o B
|
o E [origin/master]
|
o C'
|
o B'
|
o D
|
o A
|
...

Обратите внимание, что два коммитавы отличаетесь от origin, где воссоздан поверх коммита E.

...