Не удается разрешить конфликты в git из-за политики с использованием DevOps Azure

Question

Итак, у меня есть мастер ветка и ветка разработки;оба они заблокированы так, что изменения в ветвях могут быть сделаны только через запрос на извлечение.Я хочу объединить некоторые изменения из разработки в мастер на сервере, и я создал для этого запрос на извлечение.Однако были конфликты, поэтому я сделал слияние вручную локально и попытался отправить изменения на сервер.Я не могу сделать это из-за политики требования запроса на получение!Есть ли другой способ разрешить конфликты, не нарушая политику?Все, о чем я могу сейчас думать, - это отказаться от запроса на получение и создать новый, но я не уверен, что это будет делать то, что мне нужно, - нет способа реально разрешить конфликты, о которых я знаю, без локальногообъединить, и нет никакого способа получить разрешенные изменения в основную ветку, о которых я знаю, не нажимая на master, что запрещено политикой - помощь?

Answer 1

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

Существует расширение, которое может разрешить конфликт онлайн без необходимости делать это локально.

Расширение конфликта слияния с запросом на вытягивание

Answer 2

Если я понимаю ваши настройки, вы должны получить изменения в development из feature / somefeature через PR , правильно?И вы получаете изменения от превращения в master с использованием другого PR (по соглашению, поскольку политики ветвей не определяют отношения между конкретными ветвями).

Считайте, что ваше Разрешение конфликтов - это "особенность"

Откажитесь от своего текущего PR , так как он сломан без принудительного толчка.Создание новой функции / ConflictResolution ветви на основе текущей develop .Затем потяните последний master на локальный хост, и они объединятся master => feature / ConflictResolution .Это должно дать вам те же конфликты, что и в PR между разработчиком и мастером.Разрешите эти конфликты и нажмите на удаленную функцию / ConflictResolution , чтобы инициировать новый PR в разработке, а затем в мастере.

ИЛИ: поставьте свой конфликт прямо в master через PR

Это в основном то же самое, что и предыдущий параметр, за исключением того, что вы создаете PR между веткой конфликтаResolution и мастером .Я думаю, что это удалит любые изменения, которые вам нужны в PR между development и master , поэтому существующий PR может "исчезнуть" после того, как вы скажете ему повторно объединиться.

ULTIMATE ИЛИ: Прекратите использовать стратегии ветвления ада слияния

Вы по-прежнему хотите использовать стратегию на основе соединительных линий, и это нормально, но покончите с соглашением о заблокированной ветви разработки.Сохраните политику на master, убедитесь, что она требуется, добавьте в нее проверку сборки и назовите ее good.Это заставляет любые изменения, идущие в master, использовать PR и получать Restore >> Build >> Test build build.Если у вас жесткий процесс разработки, используйте теги, чтобы отметить эти церемониальные вехи в истории.

Это хорошее видео о некоторых стратегиях и о том, как они созрели и завоевали доверие со временем.

Answer 3

Я говорил с моим боссом об этом прошлой ночью, и он понял, как это сделать:

1) вытащил и мастера и разработки

2) объединены с мастером в локальную разработку

3) разрешенные конфликты

4) создан и завершен запрос на извлечение

5) вытащил разработку

Answer 4

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

Итак ..... вы уже слились с разработчиком, верно?

git reset --soft develop # put all changes related to your PR into the index, ready to commit
git commit -m "My PR changes"

Теперь все ваши изменения после разрешения всех конфликтов находятся в одной ревизии после разработки (разработка не перемещена). Нажмите эту ветку (и это должно обновить PR самостоятельно и позволить вам объединиться).