Вы можете либо, git merge masterлибо git rebase master, в этом случае я бы предпочел git rebase .

Потому что git rebaseделает так, как будто изменения в ветви функций были сделаны поверх изменений в основной ветви, что упрощает граф версий.

Rebase

Взяв пример из руководства по git rebase , git rebase masterв ветке feature:

      A---B---C feature                             A'--B'--C' feature
     /                   --rebase-->               /
D---E---F---G master                  D---E---F---G master

Однако git rebaseподходит только тогда, когда ветвь не была распределена, или возникнет путаница и дополнительная работа в нисходящем направлении, потому что старые коммиты A, B, C теперь заменены новыми коммитами A ', B', C ', плюс F и G, которые не были там раньше.

Фактический результат после git rebase masterв ветке featureэто:

      ( A---B---C )
       /
      /       A'--B'--C' feature
     /       /
D---E---F---G master

Коммиты A, B, C висят после перебазирования, но достижимы до конца git reflog feature.

Объединить

Если кто-то потянул вашу ветку или вы куда-то ее подтолкнули, вы должны вместо этого слиться с ней, чтобы избежать путаницы и дополнительной работы на другом конце. См. Восстановление из восходящей версии .

Это результат git merge masterв ветке feature:

      A---B---C feature                    A---B---C---M feature
     /                   --merge-->       /       ,---’
D---E---F---G master                 D---E---F---G master

В качестве альтернативы, если вы находитесь git merge featureв ветке master, это будет выглядеть так:

      A---B---C feature                    A---B---C feature
     /                   --merge-->       /         \
D---E---F---G master                 D---E---F---G---M master

Кристофер Хаммарстрём
источник

Вы должны объяснить, почему вы предпочитаете rebase и в чем разница. Rebase создает линейную историю - это может не соответствовать этому вопросу.

Андреас Рем

Хорошо, если я это хорошо понимаю: мне нужно оформить основную ветку, если newfeature еще не закончена, и выполнить ребаз, если она закончена?

mnml

Нет, с выделенной ветвью возможностей сделайте git rebase master, и она "перебазирует" изменения в ветви функций, чтобы они "основывались" на изменениях в основной ветке. Если изменения в основной ветке конфликтуют с изменениями в ветви функций, git попросит вас разрешить их и продолжить, пропустить или прервать. Если вы не уверены, что можете проверить тестовую ветку, чтобы попробовать ее git checkout -b test-feature feature(при условии, что ваша функциональная ветка называется «feature»).

Кристофер Хаммарстрем

Что значит "больше не вижу мою ветку"? В любом случае, git rebaseследует использовать только в том случае, если ветвь не была распространена, что, как я предполагал, имело место, поскольку вы сказали, что это новая ветка, извините за это. См. Восстановление из исходной версии в документах, с которыми я связан. Вам придется использовать git mergeвместо этого. И вы можете использовать, git reflogчтобы найти свой предыдущий заголовок ветви функции, если вы хотите получить его обратно.

Кристофер Хаммарстрем

Я никогда не видел более четкого объяснения различий между слиянием и перебазированием. Спасибо.

Пауло Педросо

GIT объединить мастер в ветку

Ответы:

Rebase

Объединить