Локальное разрешение запроса на слияние с защищенной веткой - PullRequest
0 голосов
/ 13 марта 2020

Я использую Gitlab, и у меня возник конфликт с запросом на слияние, который я не могу разрешить с помощью онлайн-инструмента. Я извлекаю целевую ветвь и разрешаю конфликт, затем ... Тогда что?

  • Ветвь защищена, поэтому никому не разрешено нажимать на нее sh.
  • На Gitlab нет никакой возможности сделать что-то подобное.

Каким должен быть правильный «способ» в этих случаях? Должны ли мы создать еще одну ветвь для решения конфликта, затем еще один запрос на слияние? Или есть строка с командой / альтернатива, которую я не смог увидеть при поиске решения, например "pu sh результат разрешения конфликта, который не является коммитом как таковым"?

Ответы [ 2 ]

0 голосов
/ 14 марта 2020

Ветвь защищена, поэтому никому не разрешено нажимать на нее sh.

Я предполагаю, что вы имеете в виду целевую ветвь, и мой ответ основан на этом.

Чтобы избежать конфликтов слияния в Gitlab, я обычно выбираю один из двух вариантов:

  1. Перебазировать ветку разработки на целевую ветку, разрешать конфликты во время перебазирования и pu sh принудительно обновлять ветку:
git checkout <development branch>
git rebase <target branch>
# optionally interactive rebase, if I have many commit I like to squash then to avoid solving the same conflicts over and over
# git rebase -i <target branch>
git push -f
Объедините целевую ветку с вашей веткой разработки локально и разрешите конфликты, передайте ее sh в gitlab, тогда у вас не должно быть конфликтов слияния на вашем MR.
0 голосов
/ 13 марта 2020

Должны ли мы создать еще одну ветвь для решения конфликта, затем еще один запрос на слияние?

Да , я бы предложил сделать это.

1) Создайте новую ветку из целевой ветви
2) Объедините в ней свою функциональную ветвь
3) Решите конфликты, добавьте их и зафиксируйте объединение
4) Pu sh, что новое филиал на удаленный
5) Создать новый PR из нового филиала на целевой

...