Потяните запрос от разработки к мастеру, вызывающему конфликты - PullRequest
0 голосов
/ 12 апреля 2019

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

Когда мы достигаем стабильной версии разработки, мы обрабатываем, чтобы превратить PR из разработки вмастер;Беда в том, что иногда мы получаем конфликты, хотя master обновляется только после разработки.

Как генерируются эти конфликты?Как возможно, чтобы какой-то Pr от разработки к мастеру имел 2 родителей?

Это граф мерзавца текущей ситуации: график главной ветки

ОБНОВЛЕНИЕ

Я почти уверен, что конфликт генерируется этим потоком:

  1. Мы работаем над функцией, а когда закончим, уничтожаем все ее коммиты и объединяем их в разработку
D: a-b-c-d-e-                                                    F
F:    \__b1-b2-b3 -> squash creates F -> rebase on develop -> __/
Разработайте его, чтобы освоить
M: a-b-c-d-e-F
D: a-b-c-d-e-F
F:           F
Разработка получает обновления, пока кто-то продолжает работать с F, и повторяет процесс сквоша и слияния с шага 1
M: a-b-c-d-e-F
D: a-b-c-d-e-F-g-h-i-                                                  J
F:           F -> f1-f2-f3 -> squash creates J -> rebase on develop __/
Разработка выпущена для освоения, и у нас есть потенциальные проблемы
M: a-b-c-d-e-F - conflicts?
D: a-b-c-d-e-F-g-h-i-J
F:                   J

Я надеюсь, что я достаточно ясно, но вкратце кажется, что на шаге 3 мы создали второго родителя для функцииветвь, и это вызывает конфликты слияния при слиянии от разработки к мастеру.Правильно ли использовать ту же функцию для PR, и после того, как он снова получит одобренную работу над ним, раздавит все его коммиты, произведет ребазинг и затем сделает с ним еще один PR?

1 Ответ

1 голос
/ 12 апреля 2019

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

Сценарий один: разработка ветки начинается с мастера.Мастер никогда не получит коммитов.Мастер получит только слияния (скажем, используя --no-ff) от разработки.Никогда не будет никакого редактирования чего-либо на мастере (без использования --no-commit) ... так что никаких хитростей.В этом случае каждый раз, когда вы сливаетесь с master, у никогда не будет никакого конфликта.И как тест, каждую ревизию слияния на master можно сравнить с ревизией, слитой с development, и не будет no отличий вообще.

Сценарий два: разработка начинается с master.... но в отличие от первого сценария, есть изменение в master, которое не находится в разработке (по какой-либо причине: переписанные ревизии с поправкой в ​​файле, ревизия, которая не в разработке .... все идет, чтобы генерировать разницу) ... все остальное идет по сценарию один .... в этом случае вы будете время от времени сталкиваться с конфликтами (когда имеете дело с кодом, связанным с различиями между ветвями).Это может быть проверено путем изменения версий слияния в master с ревизией, которая была объединена при разработке.Пока есть различия, вы будете сталкиваться с конфликтами (включая те фрагменты кода, которые были обнаружены в diff).

Дайте нам знать.

...