Как справиться с перебазированием после слияния базовой ветви? - PullRequest
0 голосов
/ 06 февраля 2020

Я разрабатывал ветвь функций (A) на основе другой ветви функций (B), и теперь ветвь, из которой я разрабатывал (B), была объединена с master.

Git теперь видит A находится в конфликте с master, потому что у меня есть изменения от B, но также и master, потому что B был объединен. Поэтому я не могу объединить A. Слияние мастера с A не имеет значения.

Как можно разрешить эту ситуацию? Перебазирование на мастера приводит к большому количеству ручного разрешения конфликтов. Моя ветка (A) не меняет никаких файлов, которые изменены в master; все конфликты проистекают из A, включая изменения B, которые уже находятся в master.

Ответы [ 2 ]

1 голос
/ 06 февраля 2020

Другой вариант, если вы уверены, что все конфликты связаны с А, включая изменения Б, - это слияние с использованием рекурсивной стратегии с нашей опцией:

Из документов:

Эта опция заставляет конфликтующие фрагменты автоматически разрешаться автоматически, предпочитая нашу версию. Изменения в другом дереве, которые не конфликтуют с нашей стороной, отражаются на результате слияния. Для двоичного файла все содержимое взято с нашей стороны.

1 голос
/ 06 февраля 2020

Обычно в этом случае вы хотите использовать git rebase --onto. Это позволяет вам указать как исходную базовую ветку, так и новую. Таким образом, вы бы сделали что-то вроде этого:

$ git checkout A
$ git rebase --onto master B

Это обрабатывает исходную базовую ветвь как B и вместо этого помещает коммиты поверх этого на master. Обычно Git обнаруживает этот случай автоматически, и сработает обычная перебазировка, хотя в некоторых случаях она не срабатывает, особенно если вы выполняете слияние sh.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...