Вытягивание со слиянием или вытягивание с перебазированием (сохранение слияний) - возможна ли разница? - PullRequest
Новая
       43

Вытягивание со слиянием или вытягивание с перебазированием (сохранение слияний) - возможна ли разница?

0 голосов
/ 08 октября 2018

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

            D     E (origin/master)
            *-----*
A    B    C/    M (master)
*----*----*-----*
 \             /
  *-----*-----*
  X     Y     Z (dev)

Вот как это развивалось:

  • Когда master был на A, мы создали ветвь объекта dev
  • Сделано совершает коммиты X, Y и Z на dev
  • Запущен репо, master был на C
  • Объединен dev вmaster, создание M
  • Между тем, коммиты D и E были сделаны на master

Так что нам нужно снова потянуть, чтобы иметь возможностьнажать на master.Я хочу рассмотреть два варианта:

  1. Pull с объединением, т. Е. git pull rebase=false
  2. Pull с сохранением слияния, т. Е. git pull rebase=preserve

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

Имейте в виду, что это упрощенная ситуация.На самом деле история между A и E, а также между X и Z может быть очень длинной и сложной.Но давайте предположим, что верно следующее: A является базой слияния для E и Z.

Без этого ограничения я могу легко ответить, что между тягой могут быть различия-слить и вытащить-ребазировать.Например, если E окажется коммитом слияния с Z вторым родителем, тогда слияние M с origin/master будет неактивным.Однако изменение этого значения на origin/master, скорее всего, приведет к конфликту.

Но если мы уверены, что ранее не было слияния dev в master, возможно ли это, что, например, первая команда выполнена успешно, а второе приводит к конфликту?

Я пытался поиграть с разными шаблонами редактирования и переименования файлов.Однако мне не удалось найти пример.Но я не могу доказать, что это невозможно.

1 Ответ

0 голосов
/ 08 октября 2018

Я не уверен, насколько можно доверять rebase -p (или rebase -r).Но я знаю более простой способ выйти из вашей ситуации.

Сохраняйте свою историю простой и не полагайтесь на сложные слияния и перебазировки.Вы можете сделать это, отменив объединение dev с мастером, обновив master, а затем снова включив dev в master. 

          D - E [origin/master]
         /
A - B - C - M [master]
 \         /
  X - Y - Z [dev]

Отменить слияние. 

git branch -f master C

          D - E [origin/master]
         /
A - B - C [master]
 \         
  X - Y - Z [dev]

Обновить master. 

git checkout master
git pull --rebase

                  [master]
A - B - C - D - E [origin/master]
 \         
  X - Y - Z [dev]

Повторите объединение. 

git merge dev

                [origin/master]
A - B - C - D - E - F [master]
 \                 /
  X - Y --------- Z [dev]

Еще лучше, перебазируйте dev на вершину мастера, проверьте его, затем объедините.

Запуск после объединенияотменить и мастер обновляется ... 

                  [master]
A - B - C - D - E [origin/master]
 \         
  X - Y - Z [dev]

Перебазировать dev поверх мастера. 

                  [master]
A - B - C - D - E [origin/master]
                 \         
                  X1 - Y1 - Z1 [dev]

Test dev.

Затем объединить с --no-ff для сохранения«характерный пузырь» в истории.Обратите внимание, что это слияние не изменится.Когда вы тестировали dev, вы также тестировали это слияние. 

                [origin/master]
A - B - C - D - E ------------ F [master]
                 \            /
                  X1 - Y1 - Z1 [dev]

Преимущество заключается в том, что вы можете протестировать dev в его окончательной завершенной форме без слияния.Он хранит историю очень просто, без лишних обновлений сливается.И это сохраняет ветку для археологии кода.

...