Что произойдет, когда я 'git pull --rebase origin development' из ветви функций?

Question

Допустим, у меня есть ветвь функции под названием FeatureAи он не синхронизирован с (удаленным) development на котором это основано. Обычно я бы перебазировал свою ветку, позвонив git rebase development (после синхронизации моего локального развития с origin/development естественно).

Сегодня я делаю это по-другому и звоню git pull --rebase origin development вместо этого из моей ветки Теперь, в чем разница?

Answer 1

git pull --rebase origin development это ярлык для этих команд:

git fetch origin development
git rebase origin/development

То есть выборка origin/development а затем перебазировать текущую ветку поверх нее.

ОБНОВИТЬ

Как отметил torek:

Да, за исключением того, что версия fetch с двумя аргументами не обновляет источник / разработку в git 1.8.3 или более ранней версии. (Результат ребазирования тот же, но происхождение / развитие не движется.)

Answer 2

Короткая версия: если ребаз идет хорошо, работает нормально. Если нет, он все еще работает так, как должен, просто может быть немного запутанным в графическом средстве просмотра.

---

Как всегда, git pull в основном git fetch а затем... ну, в этом случае, git rebase скорее, чем git merge, Так:

• извлечь из origin
• получить только development ветвь и положить это в FETCH_HEAD
• тогда вместо git merge <commit-ID-from-FETCH_HEAD>использовать git rebase с этим идентификатором

Итак, предположим, что граф коммитов в вашем локальном дереве выглядит так (предположим, что вы запустили git fetch в какой-то момент, который обновил origin/development со своими коммитами E а также F):

        C - D   <-- FeatureA
      /
A - B           <-- development
      \
        E - F   <-- origin/development

И давайте далее предположим, что на originесть еще один коммит теперь в их ветке с именем development, fetch- из исходного шага подберем и сделаем FETCH_HEAD указать на это, так что давайте нарисуем его как узел G:

        C - D       <-- FeatureA
      /
A - B               <-- development
      \
        E - F       <-- origin/development
              \
                G   <-- FETCH_HEAD

(Если ваш мерзавец достаточно новый, 1.8.4 или позже, origin/development также будет обновлено в это время, чтобы указать на узел G, Если нет, ваша локальная копия их developmentхранится в вашем origin/developmentотстает. Это не будет иметь большого значения для перебазирования, это просто изменит то, как вы увидите результаты в git log --graph просмотр или графический просмотрщик дерева коммитов.)

Теперь rebase скопирует ваш FeatureA фиксирует в обычном методе для rebase, и сделать FeatureA указать на копии, отказавшись от оригинальных коммитов. Мы позвоним перебазированным C' а также D':

        C - D       [abandoned]
      /
A - B               <-- development
      \
        E - F       <-- origin/development
              \
                G   <-- FETCH_HEAD
                  \
                    C' - D'   <-- FeatureA

Если вы управляете равниной git fetch в этот момент, или если у вас есть достаточно новый Git, чтобы origin/development переехал; и если мы отбросим "заброшенные" части и упростим чертеж, он станет:

A - B               <-- development
      \
        E - F - G   <-- origin/development
                  \
                    C' - D'   <-- FeatureA

Если вы переместитесь вперед, объедините ваш локальный ярлык development соответствовать origin/development, это еще проще нарисовать (сбросьте излом с B на E и поместите оба development а также origin/development справа от стрелки, указывающей на G).