Политики и параметры ветви

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

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

Ветвь, которая имеет необходимые политики, не может быть удалена и требует запросов на вытягивание (PR) для всех изменений.

Необходимые компоненты

  • Чтобы задать политики ветви, необходимо быть членом группы безопасности Project Администратор istrators или иметь разрешения на изменение политик на уровне репозитория. Дополнительные сведения см. в разделе "Настройка разрешений репозитория Git".

  • Если вы хотите использовать Azure DevOps CLI az repos policy commands для управления политиками ветви, выполните действия, описанные в статье "Начало работы с Azure DevOps CLI".

  • Чтобы задать политики ветви, необходимо быть членом группы безопасности Project Администратор istrators или иметь разрешения на изменение политик на уровне репозитория. Дополнительные сведения см. в разделе "Настройка разрешений репозитория Git".

Настройка политик ветви

Чтобы управлять политиками ветви, выберите "Ветви репозитория>", чтобы открыть страницу "Ветви" на веб-портале.

Снимок экрана: пункт меню

Вы также можете получить сведения о параметрах политики ветви с помощью >имени ветви политики Project Параметры> Repository>Policies.><>

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

Чтобы задать политики ветвей, найдите ветвь, которую вы хотите управлять. Вы можете просмотреть список или найти ветвь в поле "Имя ветви поиска" в правом верхнем углу.

Щелкните значок "Дополнительные параметры" рядом с ветвью и выберите политики ветви в контекстном меню.

Снимок экрана: открытие политик ветви из контекстного меню.

Найдите ветвь на странице. Вы можете просмотреть список или найти ветвь с помощью поля "Поиск всех ветвей " в правом верхнем углу.

Снимок экрана: страница

Нажмите кнопку ... . Выберите политики ветви в контекстном меню.

Снимок экрана: открытие политик ветви из контекстного меню.

Настройте политики на странице параметров ветви. В следующих разделах приведены описания и инструкции для каждого типа политики.

Настройте политики на странице "Политики ". Дополнительные сведения о каждом типе политики см. в следующих разделах. Нажмите кнопку "Сохранить изменения" , чтобы применить новую конфигурацию политики.

Снимок экрана: вкладка

Требовать минимального числа рецензентов

Проверки кода важны для проектов разработки программного обеспечения. Чтобы убедиться, что команды просматривают и утверждают PR, можно требовать утверждения от минимального количества рецензентов. Базовая политика требует, чтобы указанное число рецензентов одобрило код без отклонений.

Чтобы задать политику в разделе "Политики филиалов", установите минимальное количество рецензентов в значение "Вкл.". Введите необходимое количество рецензентов и выберите любой из следующих параметров:

Снимок экрана: включение политики

  • Выберите "Разрешить запрашивателям", чтобы утвердить свои собственные изменения , чтобы позволить создателю PR проголосовать за утверждение. В противном случае создатель по-прежнему может проголосовать за утверждение на PR, но их голосование не будет рассчитывать на минимальное количество рецензентов.

  • Выберите " Запретить последний push-запрос" от утверждения своих собственных изменений , чтобы обеспечить разделение обязанностей. По умолчанию любой пользователь с разрешением push-отправки в исходной ветви может добавлять фиксации и голосовать по утверждению PR. Выбор этого параметра означает, что последнее голосование pusher не учитывается, даже если они могут обычно утвердить свои собственные изменения.

  • Выберите "Разрешить завершение", даже если некоторые рецензенты голосуют за ожидание или отклонение , чтобы разрешить завершение PR, даже если некоторые рецензенты голосуют против утверждения. Минимальное число рецензентов по-прежнему должно утверждаться.

  • В разделе " При отправке новых изменений":
    • Выберите " Требовать по крайней мере одно утверждение" для последнего итерации , чтобы требовать хотя бы одного голосования за последнее изменение исходной ветви.
    • Выберите "Сброс всех голосов утверждения" (не сбрасывает голоса, чтобы отклонить или подождать), чтобы удалить все голоса утверждения, но сохранить голоса, чтобы отклонить или ждать, всякий раз, когда исходная ветвь изменяется.
    • Выберите "Сброс всех голосов рецензента кода", чтобы удалить все голосы рецензента при каждом изменении исходной ветви, включая голоса для утверждения, отклонения или ожидания.
  • В разделе " При отправке новых изменений":
    • Выберите " Требовать по крайней мере одно утверждение" для каждой итерации , чтобы требовать по крайней мере одного голосования за последнее изменение исходной ветви. Утверждение пользователя не учитывается в отношении предыдущей неутвержденной итерации, отправленной этим пользователем. В результате требуется дополнительное утверждение последней итерации другим пользователем. Требовать по крайней мере одно утверждение для каждой итерации доступно в Azure DevOps Server 2022.1 и выше.
    • Выберите " Требовать по крайней мере одно утверждение" для последнего итерации , чтобы требовать хотя бы одного голосования за последнее изменение исходной ветви.
    • Выберите "Сброс всех голосов утверждения" (не сбрасывает голоса, чтобы отклонить или подождать), чтобы удалить все голоса утверждения, но сохранить голоса, чтобы отклонить или ждать, всякий раз, когда исходная ветвь изменяется.
    • Выберите "Сброс всех голосов рецензента кода", чтобы удалить все голосы рецензента при каждом изменении исходной ветви, включая голоса для утверждения, отклонения или ожидания.

Установите флажок

  • Если запросы могут утвердить свои собственные изменения не выбраны, создатель запроса на вытягивание по-прежнему может проголосовать за утверждение по запросу на вытягивание, но их голосование не будет рассчитывать на минимальное количество рецензентов.
  • Если любой рецензент отклоняет изменения, запрос на вытягивание не может завершиться, если вы не выберете "Разрешить завершение", даже если некоторые рецензенты голосуют за ожидание или отклонение.
  • При отправке новых изменений в исходную ветвь можно сбросить голоса рецензента кода. При появлении новых изменений выберите "Сброс рецензента кода".

Если все остальные политики передаются, создатель может завершить pr, когда необходимое число рецензентов утверждает его.

Проверять наличие связанных рабочих элементов

Для отслеживания управления рабочими элементами можно требовать связи между PR и рабочими элементами. Связывание рабочих элементов обеспечивает больше контекста изменений и гарантирует, что обновления проходят через процесс отслеживания рабочих элементов.

Чтобы задать политику, в разделе "Политики ветви" установите флажок "Проверить наличие связанных рабочих элементоввключено". Для этого параметра требуется, чтобы рабочие элементы были связаны с PR для слияния. Сделайте параметр необязательным , чтобы предупредить, если нет связанных рабочих элементов, но разрешить завершение запроса на вытягивание.

Снимок экрана: требование связанных рабочих элементов в запросах на вытягивание.

Требовать связанные рабочие элементы в запросах на вытягивание

Проверка разрешения комментария

Проверка политики разрешения комментариев проверка, разрешаются ли все комментарии pr.

Настройте политику разрешения комментариев для ветви, установив для параметра Check for comment resolution to On. Затем выберите, нужно ли сделать политику обязательной или необязательной.

Проверка разрешения комментария

Дополнительные сведения о работе с комментариями к запросу на вытягивание см. в разделе "Просмотр запросов на вытягивание".

Настройте политику разрешения комментариев для ветви, нажав кнопку "Проверить разрешение комментариев".

Проверка разрешения комментария

Дополнительные сведения о работе с комментариями к запросу на вытягивание см. в разделе "Просмотр запросов на вытягивание".

Ограничение типов слияний

Azure Repos имеет несколько стратегий слияния, и по умолчанию все они разрешены. Вы можете поддерживать согласованный журнал ветвей, применяя стратегию слияния для завершения pr.

Задайте для типа "Ограничить слияние" значение "Вкл.", чтобы ограничить, какие типы слияний разрешаются в репозитории.

Ограничение типов слияний

  • Базовое слияние (без быстрое перемещение вперед) создает фиксацию слияния в целевом объекте, родители которого являются целевыми и исходными ветвями.
  • Слияние Squash создает линейную историю с одной фиксацией в целевой ветви с изменениями из исходной ветви. Узнайте больше о слиянии сквош и о том, как это влияет на историю ветви.
  • Перебазировка и быстрое перемещение вперед создает линейную историю путем повтора фиксаций источника в целевой ветви без фиксации слияния.
  • Перебаза с фиксацией слияния воспроизводит исходные фиксации в целевом объекте, а также создает фиксацию слияния.

Примечание.

Эта функция доступна для Azure DevOps Server 2020 и более поздних версий.

Применение стратегии слияния

Сохраняйте последовательный журнал ветвей, применяя стратегию слияния при завершении запроса на вытягивание. Выберите "Применить стратегию слияния" и выберите параметр, чтобы требовать слияние запросов на вытягивание с помощью этой стратегии.

Настройка требований к слиянию

  • Нет быстрое перемещение вперед слиянием. Этот параметр объединяет журнал фиксаций исходной ветви при закрытии запроса на вытягивание и создает фиксацию слияния в целевой ветви.
  • Слияние Squash — завершите все запросы на вытягивание с помощью слияния squash, создав одну фиксацию в целевой ветви с изменениями из исходной ветви. Узнайте больше о слиянии сквош и о том, как это влияет на историю ветви.

Проверка сборки

Вы можете задать политику, требующую изменения pr для успешной сборки, прежде чем будет завершено pr. Политики сборки сокращают разрывы и сохраняют передачу результатов теста. Политики сборки помогают, даже если вы используете непрерывную интеграцию (CI) в ветвях разработки, чтобы поймать проблемы рано.

Политика проверки сборки очереди новой сборки при создании или изменении запроса на существующую ветвь, которая нацелена на ветвь. Политика сборки оценивает результаты сборки, чтобы определить, можно ли завершить PR.

Внимание

Перед указанием политики проверки сборки необходимо иметь конвейер сборки. Если у вас нет конвейера, см. статью "Создание конвейера сборки". Выберите тип сборки, соответствующий типу проекта.

Добавление политики проверки сборки

  1. Нажмите кнопку рядом с проверкой + сборки.

    Снимок экрана: кнопка

  2. Заполните форму политики сборки Set:

    Настройка параметров политики сборки

    • Выберите конвейер сборки.

    • При необходимости задайте фильтр пути. Дополнительные сведения о фильтрах путей в политиках ветвей.

    • В разделе "Триггер" выберите "Автоматически" (при обновлении исходной ветви) или "Вручную".

    • В разделе "Требование политики" выберите "Обязательный" или "Необязательный". Если выбрано обязательное, сборки должны завершиться успешно, чтобы завершить PR. Выберите "Необязательно" , чтобы предоставить уведомление о сбое сборки, но по-прежнему разрешить выполнение PR.

    • Задайте срок действия сборки, чтобы убедиться, что обновления защищенная ветвь не прерывают изменения для открытых PR.

      • Немедленно при <обновлении имени> ветви: этот параметр задает состояние политики сборки pr на сбой при обновлении ветви и повторно отправляет сборку. Этот параметр гарантирует успешность сборки pr-запросов, даже если защищенная ветвь изменения.

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

      • После <n> часов, если <имя> ветви было обновлено: этот параметр истекает состояние текущей политики, когда защищенная ветвь обновляется, если передаваемая сборка старше порогового значения. Этот параметр является компромиссом между всегда или никогда не требует сборки при обновлении защищенная ветвь. Этот выбор уменьшает количество сборок, когда защищенная ветвь имеет частые обновления.

      • Никогда: Обновления в защищенная ветвь не изменяйте состояние политики. Это значение уменьшает количество сборок, но может вызвать проблемы при завершении PR, которые недавно не обновили.

    • Введите необязательное отображаемое имя для этой политики сборки. Это имя определяет политику на странице политик ветви. Если отображаемое имя не указано, политика использует имя конвейера сборки.

  3. Выберите Сохранить.

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

Если у вас есть немедленное <обновление имени> ветви или после <n> часов, если <имя> ветви было обновлено, состояние политики обновляется при обновлении защищенная ветвь, если предыдущая сборка больше не действительна.

Примечание.

Эта функция доступна для Azure DevOps Server 2020 и более поздних версий.

Задайте политику, требующую изменений в запросе на вытягивание, чтобы успешно создать защищенная ветвь перед завершением запроса на вытягивание. Политики сборки сокращают разрывы и сохраняют передачу результатов теста. Политики сборки помогают, даже если вы используете непрерывную интеграцию (CI) в ветвях разработки, чтобы поймать проблемы рано.

Если включена политика проверки сборки, новая сборка помещается в очередь при создании нового запроса на вытягивание или при отправке изменений в существующий запрос на вытягивание, предназначенный для ветви. Затем политика сборки оценивает результаты сборки, чтобы определить, можно ли выполнить запрос на вытягивание.

Внимание

Перед указанием политики проверки сборки необходимо иметь определение сборки. Если у вас его нет, см . статью "Создать определение сборки" и выбрать тип сборки, соответствующий типу проекта.

Добавление политики сборки

Выберите "Добавить политику сборки" и настройте параметры в разделе "Добавить политику сборки".

Настройка параметров политики сборки

  1. Выберите определение сборки.

  2. Выберите тип триггера. Выберите "Автоматически" (при обновлении исходной ветви) или вручную.

  3. Выберите требование политики. Если выбрано обязательное, сборки должны завершиться успешно, чтобы завершить запросы на вытягивание. Выберите "Необязательно" , чтобы предоставить уведомление о сбое сборки, но по-прежнему разрешить выполнение запросов на вытягивание.

  4. Задайте срок действия сборки, чтобы убедиться, что обновления защищенная ветвь не прерывают изменения для открытых запросов на вытягивание.

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

  5. Введите необязательное отображаемое имя для этой политики сборки. Это имя определяет политику на странице политик ветви. Если отображаемое имя не указано, политика использует имя определения сборки.

  6. Выберите Сохранить.

Когда владелец отправляет изменения, которые успешно создаются, состояние политики обновляется. Если выбрана политика сборки немедленно при branch name обновлении или после n обновления часыbranch name, состояние политики обновляется при обновлении защищенная ветвь, если последняя сборка больше не действительна.

Состояние проверка

Внешние службы могут использовать API состояния PR для публикации подробного состояния на PR. Политика ветви для дополнительных служб позволяет сторонним службам участвовать в рабочем процессе pr и устанавливать требования к политике.

Требовать утверждения внешних служб

Инструкции по настройке этой политики см. в разделе "Настройка политики ветви" для внешней службы.

Требовать утверждения от внешних служб

Внешние службы могут использовать API состояния PR для публикации подробного состояния на PR. Политика ветви для дополнительных служб позволяет сторонним службам участвовать в рабочем процессе pr и устанавливать требования к политике.

Требовать утверждения внешних служб

Инструкции по настройке этой политики см. в разделе "Настройка политики ветви" для внешней службы.

Автоматическое включение рецензентов кода

Вы можете автоматически добавлять рецензентов в запросы на вытягивание, изменяющие файлы в определенных каталогах и файлах, или все запросы на вытягивание в репозитории.

  1. Нажмите кнопку рядом + с автоматически включенными рецензентами.

    Снимок экрана: добавление необходимых рецензентов.

  2. Заполните экран "Добавить новую политику рецензента".

    Снимок экрана: экран

    • Добавление пользователей и групп в рецензенты.

    • Выберите "Необязательно", если вы хотите автоматически добавить рецензентов, но не требуется их утверждение для завершения запроса на вытягивание.

      Или выберите "Обязательный" , если запросы на вытягивание не могут быть завершены до тех пор, пока не будет выполнено следующее:

      • Каждый пользователь, добавленный в качестве рецензента, утверждает изменения.
      • По крайней мере один человек в каждой группе, добавленной в качестве рецензента, утверждает изменения.
      • Если требуется только одна группа, минимальное число участников, указанных вами, утверждают изменения.

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

    • Выберите "Разрешить запрашивать" утверждения собственных изменений , если владельцы запросов на вытягивание могут проголосовать за утверждение собственных запросов на вытягивание для удовлетворения этой политики.

    • Вы можете указать сообщение канала действий, которое отображается в запросе на вытягивание.

  3. Выберите Сохранить.

Примечание.

Эта функция доступна для Azure DevOps Server 2020 и более поздних версий.

Выберите рецензентов для определенных каталогов и файлов в репозитории.

Введите путь и необходимые рецензенты

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

Добавление автоматических рецензентов

Если вы выберете "Обязательный", запрос на вытягивание не может быть завершен до тех пор, пока не будет выполнено следующее:

  • Каждый пользователь, добавленный в качестве рецензента для пути, утверждает изменения.
  • По крайней мере один человек в каждой группе, добавленной в путь, утверждает изменения.
  • Число рецензентов, указанных для каждой группы, добавленной в путь, утверждает изменения.

Обязательные рецензенты добавляются автоматически

Выберите "Необязательно", если вы хотите автоматически добавить рецензентов, но не требуется их утверждение для завершения запроса на вытягивание.

Вы можете выбрать запросы, которые могут утвердить свои собственные изменения.

Когда все необходимые рецензенты утверждают код, вы можете завершить запрос на вытягивание.

Состояние запроса на вытягивание показывает, что рецензенты одобрили

Обход политик ветви

В некоторых случаях может потребоваться обойти требования политики. Обход разрешений позволяет отправлять изменения в ветвь напрямую или выполнять запросы на вытягивание, которые не удовлетворяют политикам ветви. Вы можете предоставить разрешения обхода пользователю или группе. Вы можете область обойти разрешения для всего проекта, репозитория или одной ветви.

Два разрешения позволяют пользователям обойти политику ветви разными способами:

  • Обход политик при выполнении запросов на вытягивание применяется только к завершению запроса на вытягивание. Пользователи с этим разрешением могут выполнять запросы на вытягивание, даже если запросы на вытягивание не удовлетворяют политикам.

  • Обход политик при отправке применяется к отправке из локальных репозиториев и изменений, сделанных в Интернете. Пользователи с этим разрешением могут отправлять изменения непосредственно в защищенная ветвь без требований политики.

Снимок экрана: разрешения на обход политики.

Дополнительные сведения об управлении этими разрешениями см. в разделе "Разрешения Git".

В TFS 2015–TFS 2018 с обновлением 2 разрешение на применение политики позволяет пользователям с этим разрешением выполнять следующие действия:

  • При завершении запроса на вытягивание выполните переопределение политик и завершите запрос на вытягивание, даже если текущий набор политик ветви не удовлетворен.
  • Отправка непосредственно в ветвь, даже если эта ветвь имеет набор политик ветви. Обратите внимание, что когда пользователь с этим разрешением делает push-запрос, который переопределяет политику ветви, отправка автоматически проходит политику ветви без шага или предупреждения.

Внимание

Используйте осторожность при предоставлении возможности обхода политик, особенно на уровне репозитория и проекта. Политики являются краеугольным камнем безопасного и соответствующего управления исходным кодом.

Фильтры путей

Несколько политик ветви предлагают фильтры путей. Если задан фильтр пути, политика применяется только к файлам, соответствующим фильтру пути. Оставив это поле пустым, политика применяется ко всем файлам в ветви.

Можно указать абсолютные пути (путь должен начинаться либо / с дикого карта) и дикого карта. Примеры:

  • /WebApp/Models/Data.cs
  • /WebApp/*
  • */Models/Data.cs
  • *.cs

Можно указать несколько путей, которые используются ; в качестве разделителя. Пример:

  • /WebApp/Models/Data.cs;/ClientApp/Models/Data.cs

Пути, префиксированные с помощью, ! исключаются, если они будут включены в противном случае. Пример:

  • /WebApp/*;!/WebApp/Tests/* включает все файлы за /WebApp исключением файлов в /WebApp/Tests
  • !/WebApp/Tests/* указывает, что файлы отсутствуют, так как ничего не включается в первую очередь

Порядок фильтров имеет важное значение. Фильтры применяются слева направо.

Вопросы и ответы

Можно ли отправлять изменения непосредственно в ветви с политиками ветви?

Вы не можете отправлять изменения непосредственно в ветви, которые имеют необходимые политики ветви, если у вас нет разрешений на обход политик ветви. Изменения в этих ветвях можно вносить только с помощью запросов на вытягивание. Вы можете отправлять изменения непосредственно в ветви с необязательными политиками ветви, если они не имеют обязательных политик ветви.

Что такое автозавершение?

Запросы на вытягивание в ветви с настроенными политиками ветвей имеют кнопку "Задать автозаверх ". Выберите этот параметр, чтобы автоматически завершить запрос на вытягивание после выполнения всех политик. Автозавершение полезно, если вы не ожидаете никаких проблем с изменениями.

Когда проверка условий политики ветви?

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

Можно ли использовать определения сборки XAML в политиках ветви?

Нет, нельзя использовать определения сборки XAML в политиках ветвей.

Какие дикие карта символы можно использовать для обязательных рецензентов кода?

Один звездочку * соответствует любому количеству символов, включая косую черту вперед / и косую черту \. Вопросительные знаки ? соответствуют любому одному символу.

Примеры:

  • *.sql соответствует всем файлам с расширением .sql .
  • /ConsoleApplication/* соответствует всем файлам в папке с именем ConsoleApplication.
  • /.gitattributes соответствует файлу gitattributes в корневом каталоге репозитория.
  • */.gitignore соответствует любому файлу gitignore в репозитории.

Учитывается ли регистр требуемых путей рецензента кода?

Нет, политики ветви не учитывает регистр.

Как настроить несколько пользователей в качестве необходимых рецензентов, но требовать только одного из них для утверждения?

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

У меня есть разрешения на обход политики. Почему по-прежнему отображаются ошибки политики в состоянии запроса на вытягивание?

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

Почему я не могу выполнить собственные запросы на вытягивание, когда "Разрешить запрашивателям утвердить свои собственные изменения задано"?

Как политика "Требовать минимальное количество рецензентов", так и политика автоматического включения рецензентов имеют возможность разрешить запрашивающим пользователям утвердить свои собственные изменения. В каждой политике параметр применяется только к этой политике. Этот параметр не влияет на другую политику.

Например, запрос на вытягивание имеет следующие политики:

  • Требуется минимальное количество рецензентов , для которых требуется по крайней мере один рецензент.
  • Автоматически включенные рецензенты требуют вас или команды, в которую вы находитесь в качестве рецензента.
  • Автоматически включенные рецензенты могут разрешить запрашивателям утвердить свои собственные изменения.
  • Требуется минимальное количество рецензентов , у которых нет разрешения на утверждение собственных изменений .

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

Кроме того, могут быть другие политики, такие как запретить последний push-запрос от утверждения своих собственных изменений, которые препятствуют утверждению собственных изменений, даже если запрашивающие пользователи могут утвердить свои собственные изменения .

Что происходит, когда путь в фильтрах путей не начинается ни с / диким карта?

Путь в фильтрах путей, начинающихся ни с / диким карта не будет иметь эффекта, и фильтр путей будет оцениваться так, как если бы этот путь не был указан. Это связано с тем, что такой путь не может соответствовать абсолютному / пути к файлу.