Несколько функций, разработанных параллельно, и объединение git одновременно - PullRequest
Новая
       6

Несколько функций, разработанных параллельно, и объединение git одновременно

0 голосов
/ 07 июня 2018

Имея такую ​​ситуацию в git graph: 

dev *
     \_ featureA 
      \_ featureB

, и я запросил слияния для каждой из функций в ветви dev.Обе функции разрабатываются параллельно и будут объединены в одно и то же время.

Запрос объединения филиала featureA был принят, и теперь, когда мой коллега хочет объединить featureB, он видит конфликт объединенияпотому что в CMakeLists.txt в корневом каталоге обе функции добавляют строку в файл в одном месте;в featureA: 

CMakelists.txt:10:
    add_subdirectory(featureA)

в featureB: 

CMakelists.txt:10:
    add_subdirectory(featureB)

Вопрос в том, должен ли он разрешить конфликты слиянием вручную или я должен перебазировать ветку featureB локально изатем перепроверьте ветку или, может быть, в рабочем процессе что-то не так, и в такой ситуации следует использовать другой подход?

1 Ответ

0 голосов
/ 07 июня 2018

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

Вариант 1: перебазировать, если featureB - это частная ветвь

Если featureB - это частная ветвь - то есть вы единственный, кто ее совершает, - тогда я бы рекомендовал вам перебазировать ее поверх dev после слияния featureA.

Это означает переход от этого: 

A--B---M dev
 \    /
  C--D featureA
   \
    E--F featureB

к этому: 

A--B---M dev
 \    / \
  C--D   E--F featureB

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

Выполнение перебазировки заставляет вас разрешить конфликт при коммите, который привел к конфликтующему изменению.Это имеет несколько преимуществ:

  1. Это дает вам больше контекста вокруг изменения, облегчая поиск разрешения.
  2. Разрешение станет частью самого коммита -где он принадлежит - вместо того, чтобы заканчивать коммитом слияния, потенциально смешивается с другими несвязанными разрешениями конфликтов.

Вариант 2: объединение, если featureB является публичной веткой

Еслитем не менее, featureB является публичной веткой - то есть, несколько человек принимают ее, тогда вы не можете перебазировать ее, потому что это будет переписывать историю .В этом случае вам лучше обрабатывать конфликт слияния в обычном слиянии на ветке dev.

В результате история будет выглядеть примерно так: 

A--B---M------N dev
 \    / \    /
  C--D   E--F featureB

гдеN - это место, где вы разрешаете конфликт.

...