Связь «Relates to» в GitHub Issues: когда не использовать blocks или duplicate. Для каждой пары задач задать один вопрос: есть ли зависимость исполнения, совпадает ли проблема, есть ли иерархия или нужна только контекстная связь; результат оформить как матрица выбора «нейтральный контекст → relates to; порядок → blocks; один дефект → duplicate;…
Исходная граница: issue relationships
Безопасная проверка начинается с инвентаря и неизменяемой контрольной точки. Наблюдаемая боль: Связанные задачи помечают как блокирующие или дублирующие только ради навигации, из-за чего автоматизация и отчёты получают ложную семантику зависимости. До любых действий запишите дату, точную роль, тип объекта, edition или клиент, исходное значение и ожидаемый результат. Рабочая задача этого разбора: для каждой пары задач задать один вопрос: есть ли зависимость исполнения, совпадает ли проблема, есть ли иерархия или нужна только контекстная связь. Не меняйте одновременно policy, версию клиента и содержимое проверяемого объекта: иначе результат нельзя будет связать с одной переменной. Публичная запись должна содержать только обезличенные статусы; имена, приватные адреса, токены, полный журнал и рабочее содержимое исключаются.
Доказательная база для issue relationships
Первичный источник подтверждает следующее: GitHub добавил отношение Relates to для нейтральной связи issues и развил поддержку multi-select в Projects и issues. Второй официальный источник уточняет: Предыдущее официальное объявление описывает multi-select fields; поле классификации и тип связи решают разные задачи и не должны подменять друг друга. Официальные страницы дают два слоя: факт релиза и рабочую спецификацию. Их нужно связать с effective settings конкретного контура. Поэтому ожидаемый артефакт — матрица выбора «нейтральный контекст → relates to; порядок → blocks; один дефект → duplicate; иерархия → contains; категория → field». Он фиксирует проверяемые поля и не утверждает, что функция популярна, что она уже доступна каждому аккаунту или что именно релиз вызвал любой похожий симптом. Дату и технические свойства следует брать с прямых страниц, а не из заголовка агрегатора.
Обратимый опыт: issue relationships
Контрольный тест сформулирован так: На четырёх учебных issues применить по одному типу связи, проверить отображение и automation, затем удалить связи без изменения содержимого задач. Перед началом сохраните исходное значение, идентификатор тестового объекта и способ возврата. Выполните одно действие, дождитесь одного измеримого ответа и внесите его в матрица выбора «нейтральный контекст → relates to; порядок → blocks; один дефект → duplicate; иерархия → contains; категория → field». Положительный результат подтверждает только эту ветку в данном окружении; отрицательный исключает только проверенное условие. Повтор допустим на той же версии и с теми же входными данными, без серии очисток, переустановок и расширения прав.
Матрица решений по issue relationships
Сначала сравните expected и actual для контрольного объекта. Если они совпали, выполните возврат и подтвердите, что исходное состояние восстановлено. Если не совпали, проверьте effective role, policy, scope и version, затем переходите только к одной соседней ветке. Основной инструмент — матрица выбора «нейтральный контекст → relates to; порядок → blocks; один дефект → duplicate; иерархия → contains; категория → field». Отдельная строка нужна для неизвестного состояния: она честнее преждевременного диагноза. Совпадение даты или названия не доказывает регрессию; доказательством служит воспроизводимый before/after с одной изменённой переменной и границей из официальной документации.
Стоп-линия и эскалация: issue relationships
Критерий остановки: Не менять массово историю проекта, если отчёты или automation завязаны на прежний relationship и нет карты миграции. Для эскалации подготовьте минимальный пакет: UTC-время, версию клиента или API, тип аккаунта, обезличенный идентификатор объекта, expected и actual, один контрольный шаг, результат возврата и ссылки на два официальных источника. Скриншот обрежьте до нужной области. Не прикладывайте приватные URL, email, секреты, конфигурацию организации целиком, database, HAR или необработанный лог. Такой пакет позволяет проверить именно «issue relationships» без опасных необратимых изменений.
Материал подготовлен редакцией VOne с помощью ИИ; все технические утверждения постатейно сверены с указанными официальными источниками 28 августа 2026 года.
Источники и проверка
- Официальный GitHub Changelog проверено 2026-08-28
- Официальная техническая документация проверено 2026-08-28
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.