git rebase upstream / master vs git pull --rebase upstream master

git pull --rebase сначала будет fetch (git fetch), обновив upstream/master коммиты.

Если вы просто переустановите без первого обновления upstream/master, вы не получите того же результата.

Я проиллюстрировал это на примере master ветки и «origin/master» разошлись, как «разделить» ветки?

SnakE упоминает в комментариях, что git pull --rebase не точно git fetch && git rebase origin/master.
См. что делает git pull --rebase?

(origin/master)
   |
A--B--C (master)
 \ 
  B'--D (actual origin/master after changing B and force pushing)

В этом случае git pull --rebase делает следующее:

git fetch origin
git rebase --onto origin/master B master

Здесь:

• origin / master - это новый обновленный origin/master (B')
• B - старый origin/master (до того, как он был обновлен при загрузке)
• master - ветка для воспроизведения поверх origin/master

Это отличается от git fetch + git rebase origin/master тем, что команда pull --rebase пытается выяснить, какие коммиты являются действительно вашими локальными, а какие были получены из восходящего потока в более ранней выборке.

Для этого он просматривает журнал ссылок ветки удаленного отслеживания (в данном случае origin/master). Этот журнал ссылок представляет собой подсказки по последовательным git fetch операциям на origin в самом последнем первом порядке.

Для каждой записи reflog (origin/master@{1}, затем ...{2} и так далее) он проверяет, является ли эта фиксация предком текущей заголовка ветки master. Как только он находит его, он выбирает его в качестве отправной точки для перебазирования (B в приведенном выше примере).