Как включить Require conversation resolution в GitHub перед merge

Чем conversation resolution отличается от approval

Require conversation resolution закрывает отдельную дыру в review-процессе: PR может иметь нужный approval, но внутри обсуждения всё ещё оставаться нерешённый вопрос. При включённом правиле GitHub не разрешит merge, пока такие review threads не помечены resolved. Поэтому его имеет смысл использовать вместе с required reviews, а не вместо них. Перед включением на основной ветке проверьте поведение на тестовом PR с одним открытым комментарием — так видно, что блокирует merge именно conversation resolution, а не другой ruleset или status check.

Совет: Проверяйте правило на отдельном PR с одним намеренно открытым review-тредом — причина блокировки будет однозначной.

Что сделать по шагам

1. Откройте Settings репозитория и правило целевой ветки.
2. Выберите защиту main или другой release-ветки.
3. Включите Require conversation resolution before merging.
4. Сохраните правило и создайте тестовый PR с review-комментарием.
5. Убедитесь, что merge заблокирован до Resolve conversation.

Предупреждение: Не используйте Resolve, чтобы скрыть нерешённый вопрос — сначала зафиксируйте решение в треде.

Что важно учесть в текущей реализации

Require conversation resolution проверяет именно открытые review-обсуждения, а не наличие общего approval. GitHub не разрешит merge в защищённую ветку, пока каждый conversation thread не будет отмечен как resolved. Поэтому правило полезно вместе с required reviews: одно требует одобрение, другое не даёт забыть конкретный незакрытый вопрос. Для теста создайте PR, оставьте review comment и убедитесь, что кнопка merge заблокирована; затем ответьте в треде, нажмите Resolve conversation и проверьте, что исчезла именно эта причина блокировки. Внутри команды стоит заранее договориться, кто закрывает тред: технически GitHub хранит состояние, но качество процесса зависит от того, не используется ли Resolve для замалчивания нерешённого замечания.

Важно: Проверьте параллельные rulesets: GitHub может применять несколько наборов правил.

Проверка результата и крайние случаи

После включения правила создайте PR, оставьте review comment и не закрывайте conversation. Merge должен оставаться заблокированным даже при наличии approval, пока тред не будет resolved. Затем нажмите Resolve conversation и убедитесь, что исчезла именно эта причина блокировки; required checks или другие rulesets могут продолжать удерживать PR. В командной практике полезно договориться, кто имеет право закрывать спорный тред и что должно быть написано в последнем ответе. Техническая кнопка Resolve не заменяет фактическое исправление замечания.

Контрольный список

• На тестовом PR есть намеренно открытый review thread.
• Merge блокируется до Resolve conversation.
• После resolve исчезает именно эта причина блокировки.
• Required reviews/checks остаются отдельными требованиями.

Финальная проверка

Если после Resolve merge всё ещё заблокирован, откройте список требований PR и найдите другой failing check вместо повторного изменения conversation rule.

Ожидаемый результат

На тестовом PR оставьте conversation открытым и затем resolve его: сначала merge блокируется этим требованием, после resolve — снимается именно эта причина.

Что учитывать

Require conversation resolution проверяет именно открытые review-обсуждения, а не наличие общего approval. GitHub не разрешит merge в защищённую ветку, пока каждый conversation thread не будет отмечен как resolved. Поэтому правило полезно вместе с required reviews: одно требует одобрение, другое не даёт забыть конкретный незакрытый вопрос. Для теста создайте PR, оставьте review comment и убедитесь, что кнопка merge заблокирована; затем ответьте в треде, нажмите Resolve conversation и проверьте…

Источники и проверка

Инструкция составлена редакцией N1RO на 2026-09-22. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.

• About protected branches