Разрешение PR-конфликта в DevOps Azure без изменения ветки источника

Question

У нас есть две ветки git с ограниченным доступом в DevOps Azure,

• test ветка для среды UAT
• master ветка для производственной среды

Разработчики не могут зафиксировать эти ветви напрямую , они должны создавать PR, чтобы объединить свои собственные ветви. И они основывают свои собственные ветви на master.

Если PR утвержден, то он будет объединен с test ответвлением и развернут в UAT env. Если клиент / пользователь принимает изменения в ветке test, мы объединяем эти PR с веткой master для развертывания в prod env. PR в test филиале могут не принять клиентом, и затем они не будут объединены с master филиалом. Таким образом, мы не можем переназначить ветви функций на test, или мы не можем объединить тест с этими ветками функций, потому что не каждый коммит в test переходит к master.

Есливозникает конфликт при создании PR для ветки test, мы должны разрешить этот конфликт без изменения исходной ветки, а коммит слияния должен остаться в ветке test. Мы не можем перейти на test, потому что, как я уже говорил, не каждый пиар в test будет сливаться с master. Поэтому мы используем это расширение в качестве обходного пути, но оно бесполезно, как инструмент слияния в Visual Studio: Расширение PR-конфликта

Есть ли способ добиться этого без использования этого расширения и с использованием Visual Studioинструмент слияния? Или вы могли бы предложить другой способ разрешения PR-конфликтов без фиксации дополнительного слияния с исходной веткой?

Answer 1

На самом деле, конфликт PR EXtension также может разрешить конфликт PR, не изменяя исходную ветвь.

Как видите, исходная ветвь - это branch1, а целевая ветвь - master. Есть конфликт в пиаре.

На вкладке «Конфликт» вы можете выбрать «Взять исходный файл», чтобы разрешить конфликт, и он не изменит ветку источника.

После завершения PR ниже приведены основные коммиты и ветвь коммитов. И нет никаких изменений в исходной ветке (branch1).

Существует только одно различие между разрешением конфликта слияния с помощью инструмента слияния Visual Studio и расширением конфликта PR. В истории ветвей нет фиксации разрешения конфликта. Но это потому, что средство слияния Visual Studio разрешило конфликт в локальной ветви и переместило измененный файл в Azure Repo, так что это всего один коммит об обновлении.

Расширение конфликта PR напрямую изменяет файл вAzure репо, поэтому история фиксации будет включать в себя этап разрешения конфликта.