VSTS: как потребовать обновления ветки перед слиянием (выполнение запроса на извлечение) из этой ветки?

#git #github #azure-devops #azure-pipelines

#git #github #azure-devops #azure-конвейеры

Вопрос:

В Github можно потребовать обновления ветки, прежде чем ее можно будет объединить: см. https://github.community/t/best-practices-for-protected-branches/10204

Также включив требование обновления ветвей перед слиянием, вы можете убедиться, что проверки выполняются по последнему состоянию целевой ветки

Как можно обеспечить это в Azure DevOps?

Ответ №1:

VSTS: как потребовать обновления ветки перед слиянием (выполнение запроса на извлечение) из этой ветки?

Однажды у меня был такой же запрос, как и у вас, но после периода исследований и тестов я обнаружил, что это уникальная особенность github. Azure devops не имеет аналогичной функции Require branches to be up to date before merging в github:

введите описание изображения здесь

Как вы и сказали, разработчики или запрашивающие могут разрешить конфликт до завершения PR, однако рецензенты все равно будут получать эти конфликтующие PR. Очевидно, что это прерывание для рецензентов.

Я думал, что раньше я был единственным, у кого был специальный запрос. Поскольку сейчас у нас один и тот же запрос, я добавляю этот запрос для этой функции на сайт UserVoice, который является основным форумом для предложений продуктов:

Azure devops поддерживает функцию «Требовать обновления ветвей перед объединением»

Вы можете проголосовать за это и добавить свой комментарий бесплатно.

Ответ №2:

Если вы хотите убедиться, что сборка в PR всегда будет выполняться с последней целевой веткой, вам необходимо настроить «Срок действия сборки» на «Немедленно при обновлении «имя ветки»».

введите описание изображения здесь

Смотрите Документы здесь:

Немедленно при обновлении имени ветки: этот параметр устанавливает статус политики сборки в запросе на извлечение на сбой при обновлении защищенной ветки. Запросите сборку, чтобы обновить статус сборки. Этот параметр гарантирует, что изменения в запросах на извлечение будут успешно выполняться даже при изменении защищенной ветки. Этот вариант лучше всего подходит для команд, у которых есть важные ветки с меньшим объемом изменений. Командам, работающим в занятых ветвях разработки, может показаться неудобным ждать завершения сборки каждый раз, когда обновляется защищенная ветка.

Комментарии:

1. Проблема, которую мы хотим решить, заключается в том, что люди выполняют запросы на извлечение без предварительного обновления из main, тем самым оставляя сопровождающему main выполнять все разрешения конфликтов. Если разработчик вынужден переходить из main в свою ветку, чтобы убедиться, что его ветка обновлена, прежде чем выполнять PR в main из своей ветки, ему придется самому редактировать конфликты. т. Е. Ничего общего с какой-либо сборкой. Если не существует какого-либо другого правила, которое предотвратит слияние ветки с main, если статус политики сборки false , это не остановит создание PR из устаревшей ветки.

2. О, хорошо, я пропустил, что в GitHub требуется, чтобы ветка pr выполняла слияние с целевой (основной). но в Azure DevOps, если есть конфликты, вы не можете завершить слияние, поэтому запрашивающий pr должен сам решать конфликты.

3. Запрашивающий PR может разрешить конфликты, но ему это не нужно. Он может оставить это на усмотрение любого другого, у которого есть права утверждать PR. PR будет оставаться там неутвержденным до тех пор, пока есть конфликты. Мы хотим сделать так, чтобы инициатор запроса PR всегда разрешал конфликты.

4. В GitHub также есть только «появится сообщение, указывающее, что эти изменения необходимо объединить вверх по потоку в ветку запроса на извлечение перед слиянием», запрос PR может «прослушивать» сообщение или нет, PR также может оставаться там неутвержденным, пока есть конфликты. в чем разница?

5. Если в GitHub вы включили строгую защиту ветвей, то «ветка должна быть обновлена до слияния». Таким образом, разработчик должен убедиться, что его ветка обновлена, поэтому конфликты сначала появятся в его ветке. Возможно, ничто не заставляет его разрешать конфликты в своей собственной ветке, прежде чем выполнять PR в main. Я не проверял, какие сообщения в Github, но, вероятно, это будет «ветка требует обновления», а не «ветка требует обновления, и вот некоторые конфликты для редактирования из-за этого»