GitHub AE release notes

Владельцы предприятия могут присоединяться к организациям в GitHub AE в качестве участника или владельца на странице Организации корпоративной учетной записи. Дополнительные сведения см. в статье Управление ролью в организации, принадлежащей предприятию.

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

Владельцы предприятий могут запретить владельцам организации приглашать участников совместной работы в репозитории GitHub AE. Дополнительные сведения см. в разделе Применение политики для приглашения участников совместной работы в репозитории.

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

• "События и полезные данные веб-перехватчика" в документации по веб-перехватчику
• Управление параметрами безопасности и анализа для организации
• Управление функциями безопасности и анализа для репозитория

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

• "Защита push-уведомлений с помощью сканирования секретов"
• "События журнала аудита для предприятия"
• Просмотр журнала аудита для организации
• "Проверка секретов" в документации по REST API

Теперь владельцы организации могут настроить два новых разрешения для проверки секретов при управлении настраиваемыми ролями репозитория.

• Просмотр результатов проверки секретов
• Закрытие или повторное открытие результатов проверки секретов

Дополнительные сведения см. в разделе Управление ролями репозитория для организации.

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

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

Проверка секретов предотвращает утечку секретов в веб-редакторе. Дополнительные сведения см. в разделе Защита push-уведомлений с помощью сканирования секретов.

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

• C# 10 / .NET 6
• Python 3.10
• Java 17
• TypeScript 4.5

Дополнительные сведения см. в блоге GitHub.

Владельцы организации и менеджеры по безопасности могут просматривать оповещения сканирования кода на вкладке Безопасность организации. Дополнительные сведения см. в разделе Общие сведения о безопасности.

Теперь на странице оповещений сканирования кода всегда отображаются состояние оповещения и сведения для ветвь по умолчанию. На боковой панели есть новая панель "Затронутые ветви", где можно просмотреть состояние оповещения в других ветвях. Если оповещение не существует в ветвь по умолчанию, на странице оповещения будет отображаться состояние "В ветви" или "В запросе на вытягивание" для расположения, в котором оповещение было видно в последний раз. Это улучшение упрощает понимание состояния оповещений, которые были введены в базу кода. Дополнительные сведения см. в статье Сведения об оповещениях проверки кода. Страница списка оповещений не изменяется и может быть отфильтровано по .branch Api сканирования кода можно использовать для получения более подробных сведений об ветвях для оповещений. Дополнительные сведения см. в разделе "Проверка кода" в документации по REST API.

Теперь при проверке кода отображаются сведения о источнике анализа оповещения. Если оповещение имеет несколько источников анализа, оно отображается на боковой панели "Затронутые ветви" и в временная шкала оповещения. Пользователи могут навести указатель мыши на значок источника анализа на боковой панели "Затронутые ветви", чтобы увидеть состояние оповещения в каждом источнике анализа. Если оповещение имеет только один источник анализа, сведения об источниках анализа не отображаются на странице оповещения. Эти улучшения упрощают понимание оповещений. В частности, это поможет пользователям понять те, которые имеют несколько источников анализа. Это особенно полезно для установки с несколькими конфигурациями анализа, такими как monorepos. Дополнительные сведения см. в статье Сведения об оповещениях проверки кода.

Пользователи могут использовать sort параметры и direction в REST API при получении оповещений сканирования секретов и выполнять сортировку на основе полей или updated оповещенийcreated. Новые параметры доступны для всех развертываний GitHub AE, а также для отдельных организаций или репозиториев. Дополнительные сведения см. в следующей документации.

• Вывод списка оповещений сканирования секретов для предприятия
• "Вывод списка оповещений сканирования секретов для организации"
• Вывод списка оповещений сканирования секретов для репозитория
• "Проверка секретов" в документации по REST API

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

При необходимости пользователи могут добавить комментарий при закрытии оповещения сканирования кода в пользовательском веб-интерфейсе или с помощью REST API. Комментарии о закрытии отображаются в событии временная шкала. Пользователи также могут добавлять или извлекать комментарии о закрытии с помощью REST API. Дополнительные сведения см. в разделах "Анализ оповещений сканирования кода в запросах на вытягивание" и "Сканирование кода" документации по REST API.

Теперь пользователи могут получать оповещения о проверке кода для организации с помощью REST API. Эта новая конечная точка API дополняет существующую конечную точку для репозиториев. Дополнительные сведения см. в разделе "Проверка кода" в документации по REST API.

Содержимое репозитория перемещено в github/codeql-go репозиторий github/codeql , чтобы жить вместе с аналогичными библиотеками для всех других языков программирования, поддерживаемых CodeQL. Запросы CodeQL с открытым кодом, библиотеки и средства извлечения для анализа баз кода, написанных на языке программирования Go с помощью средств анализа кода CodeQL на GitHub, теперь можно найти в новом расположении. Дополнительные сведения, включая рекомендации по переносу существующих рабочих процессов, см. в статье github/codeql-go#741.

Владельцы предприятия могут просматривать обзор оповещений Dependabot в развертывании GitHub AE, включая представление о рисках безопасности приложений, ориентированное на репозиторий, а также представление всех оповещений о проверке секретов и оповещениях Dependabot. Представления находятся в бета-версии и могут быть изменены. Дополнительные сведения см. в статье Просмотр общих сведений о безопасности.

Владельцы организации и менеджеры по безопасности могут просматривать оповещения Dependabot на вкладке Безопасность организации. Дополнительные сведения см. в разделе Общие сведения о безопасности.

Пользователи могут повторно открыть оповещение Dependabot с помощью пользовательского веб-интерфейса. Это не влияет на запросы на вытягивание Dependabot или API GraphQL. Дополнительные сведения см. в разделе Сведения об оповещениях Dependabot.

Пользователи могут просматривать фиксированные оповещения из Dependabot с помощью API GraphQL. Пользователи также могут получать доступ и фильтровать по состоянию, а также по уникальному числовому идентификатору и фильтровать по состоянию в объекте оповещения об уязвимости. Следующие поля теперь существуют для RepositoryVulnerabilityAlert.

• number
• fixed_at
• fix_reason
• state

Дополнительные сведения см. в разделе Объекты документации по API GraphQL.

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

GitHub Actions может применять проверки зависимостей к запросам на вытягивание пользователей путем проверки на наличие зависимостей и будет предупреждать пользователей о связанных уязвимостях системы безопасности. Это dependency-review-action действие поддерживается новой конечной точкой API, которая разделяет зависимости между любыми двумя редакциями. Дополнительные сведения см. в статье "Сведения о проверке зависимостей".

Граф зависимостей обнаруживает YAML-файлы для GitHub Actions рабочих процессов. GitHub AE отобразит файлы рабочего процесса в разделе граф зависимостей вкладки Аналитика. Репозитории, которые публикуют действия, также смогут видеть количество репозиториев, зависящих от этого действия, из элемента управления "Используется" на домашней странице репозитория. Дополнительные сведения см. в разделе Сведения о графе зависимостей.

Граф зависимостей обнаруживает Cargo.toml файлы и Cargo.lock для Rust. Эти файлы будут отображаться в разделе Граф зависимостей на вкладке Аналитика . Пользователи будут получать оповещения и обновления Dependabot об уязвимостях, связанных с их зависимостями Rust. Метаданные пакета, включая пакеты сопоставления с репозиториями, будут добавлены позже. Дополнительные сведения см. в разделе Сведения о графе зависимостей.

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

• Управление GitHub Connect
• "Просмотр уязвимостей системы безопасности в базе данных рекомендаций GitHub" в документации по GitHub Enterprise Cloud
• Сведения о рекомендациях по безопасности GitHub для репозиториев в документации по GitHub Enterprise Cloud
• "Изменение рекомендаций по безопасности в базе данных рекомендаций GitHub" в документации по GitHub Enterprise Cloud

Люди, которые поддерживают локальные средства выполнения тестов, теперь имеют больший контроль над тем, когда они выполняют обновления программного обеспечения. Если вы укажете --disableupdate для средства выполнения тестов флаг, средство выполнения тестов не будет пытаться выполнить автоматическое обновление программного обеспечения, если доступна более новая версия программного обеспечения средства выполнения. Это позволяет обновлять локальное средство выполнения по пользовательскому расписанию и особенно удобно, если локальное средство выполнения тестов находится в контейнере. Для обеспечения совместимости со службой GitHub Actions программное обеспечение средства выполнения должно быть обновлено в течение 30 дней после того, как будет доступна новая версия средства выполнения. Дополнительные сведения об установке последней версии средства выполнения тестов см. в инструкциях по установке последнего выпуска в actions/runner.

При использовании GitHub Actions, чтобы снизить риск объединения изменений, которые не были проверены другим лицом, в защищенная ветвь, владельцы предприятия и администраторы репозитория могут запретить действиям создавать запросы на вытягивание. Владельцы организации ранее могли включить это ограничение. Дополнительные сведения см. в следующих руководствах.

• Применение политик для GitHub Actions на предприятии
• "Отключение или ограничение GitHub Actions для вашей организации"
• Управление параметрами GitHub Actions для репозитория

Владельцы организации могут повысить безопасность рабочих процессов CI/CD в локальных средствах выполнения, выбрав, какие рабочие процессы могут получить доступ к группе средств выполнения. Ранее любой рабочий процесс в репозитории, например средство маркировки проблем, мог получить доступ к локальным средствам выполнения тестов, доступным для организации. Дополнительные сведения см. в разделе Управление доступом к локальным средствам выполнения тестов с помощью групп и блоге GitHub.

Владельцы организации могут контролировать, могут ли GitHub Actions утверждать запросы на вытягивание. Эта функция защищает от пользователей, использующих GitHub Actions для удовлетворения требования защиты ветви "Необходимые утверждения" и объединения изменений, которые не были проверены другим пользователем. Чтобы предотвратить нарушение существующих рабочих процессов, по умолчанию включен параметр Разрешить проверкам GitHub Actions учитываться при обязательном утверждении. Владельцы организации могут отключить эту функцию в параметрах GitHub Actions организации. Дополнительные сведения см. в разделе Отключение или ограничение GitHub Actions для организации.

Пользователи могут написать один рабочий процесс, активированный workflow_dispatch и workflow_call, и использовать inputs контекст для доступа к входным значениям. Ранее workflow_dispatch входные данные были в полезных данных события, что усложняло работу авторов рабочих процессов, которые хотели написать один рабочий процесс, который можно было использовать повторно и активировать вручную. Для рабочих процессов, активированных , workflow_dispatchвходные данные по-прежнему доступны в контексте github.event.inputs для поддержания совместимости. Дополнительные сведения см. в разделе «Контексты».

Теперь пользователи могут повторно запускать только невыполненые задания или отдельные задания в GitHub Actions рабочем процессе. Дополнительные сведения см. в статье Повторный запуск рабочих процессов и заданий.

Чтобы подвести итоги задания, пользователи могут создать Markdown и опубликовать его содержимое в виде сводки задания. Например, после выполнения тестов с GitHub Actions сводка может содержать общие сведения о пройденных, неудачных или пропущенных тестах, что может снизить потребность в просмотре полных выходных данных журнала. Дополнительные сведения см. в разделе Команды рабочего процесса для GitHub Actions.

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

Если вы управляете локальными средствами выполнения для GitHub Actions, можно обеспечить согласованное состояние самого средства выполнения до и после запуска рабочего процесса, определив скрипты для выполнения. При использовании скриптов вам больше не нужно требовать, чтобы пользователи вручную включали эти шаги в рабочие процессы. Скрипты до и после задания находятся в бета-версии и могут быть изменены. Дополнительные сведения см. в разделе Выполнение скриптов до или после задания.

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

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

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

Пользователи могут удалить ветвь, связанную с открытым запросом на вытягивание. Дополнительные сведения см. в разделе Создание и удаление ветвей репозитория.

CODEOWNERS получил следующие улучшения.

• Синтаксические ошибки теперь отображаются при просмотре файла CODEOWNERS из пользовательского веб-интерфейса. Ранее, когда строка в файле CODEOWNERS имела синтаксическую ошибку, эта ошибка игнорирулась или в некоторых случаях приводила к тому, что весь файл CODEOWNERS не загружался. Приложения и действия GitHub могут получить доступ к одному и тому же списку ошибок с помощью новых API REST и GraphQL. Дополнительные сведения см. в разделе "Репозитории" в документации по REST API или в разделе "Объекты" в документации по API GraphQL.
• Когда кто-то создает новый запрос на вытягивание или отправляет новые изменения в черновик запроса на вытягивание, все владельцы кода, которые будут запрошены для проверки, теперь отображаются в запросе на вытягивание в разделе "Рецензенты". Эта функция позволяет заранее определить, кому будет предложено проверить, как только запрос на вытягивание будет помечен как готовый к проверке.
• Комментарии в файлах CODEOWNERS теперь могут отображаться в конце строки, а не только в выделенных строках.

Дополнительные сведения см. в разделе Сведения о владельцах кода.

Когда пользователь переименовывает или перемещает файл в новый каталог, если по крайней мере половина содержимого файла идентична, журнал фиксаций указывает на то, что файл был переименован, аналогично git log --follow. Дополнительные сведения см. в блоге GitHub.

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

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

Пользователи могут игнорировать редакции в представлении blame, создав .git-blame-ignore-revs файл в корне репозитория. Дополнительные сведения см. в разделе Просмотр файла.

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

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

Чтобы подтвердить, что фиксация соответствует правилам и лицензированию репозитория, владельцы организации и администраторы репозитория теперь могут требовать от разработчиков подписи фиксаций, сделанных через веб-интерфейс. Дополнительные сведения см. в разделах Управление политикой подписи фиксации для организации и Управление политикой подписи фиксации для репозитория.

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

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

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

• Если ветвь раздела запроса на вытягивание устарела с базовая ветвь, пользователи могут обновить ветвь, перерастовив ее на последнюю версию базовая ветвь. При перебазовке изменения из ветви раздела применяются к последней версии базовая ветвь, что приводит к созданию ветви с линейным журналом, так как фиксация слияния не создается. Чтобы выполнить обновление путем повторного базирования, щелкните раскрывающееся меню рядом с кнопкой Обновить ветвь , щелкните Обновить с перебазированием, а затем выберите Команду Перебазировать ветвь. Ранее ветвь Обновления выполняла традиционное слияние, которое всегда приводило к фиксации слияния в ветви запроса на вытягивание. Этот параметр по-прежнему доступен, но теперь у пользователей есть выбор. Дополнительные сведения см. в разделе Синхронизация запроса на вытягивание с базовой ветвью.
• Новый параметр репозитория позволяет всегда быть доступной кнопке Обновить ветвь, если ветвь раздела запроса на вытягивание не соответствует базовая ветвь. Ранее эта кнопка была доступна только в том случае, если параметр Требовать актуальность ветвей перед слиянием защиты ветви был включен. Люди с правами администратора или ведения может управлять параметром Всегда предлагать обновление ветвей запросов на вытягивание из раздела Запросы на вытягивание в параметрах репозитория. Дополнительные сведения см. в разделе Управление предложениями по обновлению ветвей запросов на вытягивание.

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

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

Теперь при первом отображении отображаются только 30 последних комментариев. Пользователи могут нажать кнопку Загрузить предыдущие комментарии... для просмотра дополнительных сведений. Это позволяет гистам с большим количеством комментариев отображаться быстрее. Дополнительные сведения см. в разделе Изменение содержимого и предоставление общего доступа к содержимому с помощью gist.

Улучшено редактирование Markdown в веб-интерфейсе.

• После того как пользователь выберет текст и вставляет URL-адрес, выделенный текст станет ссылкой Markdown на вставленный URL-адрес.
• Когда пользователь вставляет ячейки электронной таблицы или HTML-таблицы, результирующий текст будет отображаться в виде таблицы.
• Когда пользователь копирует текст, содержащий ссылки, вставляемый текст будет включать ссылку в виде ссылки Markdown.

Дополнительные сведения см. в разделе Базовый синтаксис записи и форматирования.

При редактировании файла Markdown в веб-интерфейсе при нажатии вкладки Предварительный просмотр автоматически прокрутится до места в режиме предварительного просмотра, которое вы редактировали. Расположение прокрутки зависит от положения курсора перед переходом на вкладку Предварительный просмотр .

Теперь доступна светлая тема с высокой контрастностью между элементами переднего плана и фона. Дополнительные сведения см. в разделе Управление параметрами темы.

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

GitHub AE может отображать несколько распространенных форматов изображений, включая PNG, JPG, GIF, PSD и SVG, а также предоставляет несколько способов сравнения различий между версиями. При просмотре добавленных или измененных изображений в запросе на вытягивание предварительные просмотры этих изображений теперь отображаются по умолчанию. Ранее пользователи могли видеть сообщение о том, что двоичные файлы не отображаются, и должны были переключить параметр "Отображать форматированные diff". Дополнительные сведения см. в разделе Работа с файлами без кода.

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

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

При наведении фокуса или наведении указателя мыши на метку теперь отображается подсказка с описанием метки.

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

Чтобы использовать поток авторизации устройства для приложений OAuth и GitHub, авторы приложений должны вручную включить эту функцию. Это изменение снижает вероятность использования приложений в фишинговых атаках на пользователей GitHub AE, гарантируя, что интеграторы знают о рисках и делают сознательный выбор для поддержки этой формы проверки подлинности. Пользователи, которые владеют или управляют Приложение OAuth или Приложение GitHub и хотят использовать поток устройства, могут включить его для приложения на странице параметров приложения. Конечные точки API потока устройств будут отвечать кодом 400 состояния для приложений, которые не включили эту функцию. Дополнительные сведения см. в разделе Авторизация приложений OAuth.

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

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

Дополнительные сведения см. в разделе Управление командами и людьми, имеющими доступ к репозиторию.

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

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

Обновленный интерфейс управления для локальных средств выполнения тестов упрощает управление группами средств выполнения и предоставляет улучшенный обзор средств выполнения. Дополнительные сведения см. в разделах Сведения о локальных средствах выполнения тестов и Управление доступом к локальным средствам выполнения с помощью групп.

Dependabot теперь делится секретами с GitHub Actions, когда Dependabot запускает выполнение рабочего процесса, поэтому пользователи теперь могут извлекать из частных реестров пакетов в конвейерах CI с помощью секретов Dependabot. Дополнительные сведения см. в разделе Управление зашифрованными секретами для Dependabot.

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

Пользователи могут улучшить взаимодействие с рабочим процессом, указав типы входных данных для рабочих процессов, запускаемых вручную. Рабочие процессы теперь поддерживают choice, booleanи environment. Дополнительные сведения см. в статье "Синтаксис рабочего процесса для GitHub Actions".

Первое доступное соответствующее средство выполнения на уровне репозитория, организации или предприятия будет выполнять каждое задание во всех случаях. Это означает, что задания отправляются в локальные средства выполнения тестов гораздо быстрее, особенно для организаций и предприятий с большим количеством локальных средств выполнения. Ранее при выполнении задания, требующего локального средства выполнения тестов, GitHub Actions искали локальные средства выполнения в репозитории, организации и на предприятии в этом порядке. Дополнительные сведения см. в разделе Использование локальных средств выполнения тестов в рабочем процессе.

Пользователи могут указать, что действие JavaScript должно выполняться в Node.js 16, указав runs.using как node16. Node.js 16 поддержка дополняет существующую поддержку для Node.js 12. Средства выполнения должны иметь версию 2.285.0 или более позднюю версию средства выполнения GitHub Actions. Дополнительные сведения см. в разделе Синтаксис метаданных для GitHub Actions и репозиторийactions/runner.

Пользователи могут добавлять, перечислять и удалять метки для локальных средств выполнения с помощью REST API. Дополнительные сведения см. в разделе Локальные средства выполнения тестов в документации по REST API.

Пользователи могут повысить безопасность служб и средств, созданных с помощью Ruby, с помощью сканирования кода CodeQL. Для всех распространенных версий Ruby до версии 3.02 CodeQL может обнаруживать распространенные проблемы, такие как внедрение КОДА SQL, ReDoS, внедрение команд и аргументов ОС, расширение сущности XML, отраженные межсайтовые скрипты (XSS), хранимые XSS, небезопасная десериализация и жестко закодированные учетные данные. Чтобы включить анализ Ruby, пользователям необходимо обновить существующий файл рабочего процесса сканирования кода CodeQL. Поддержка Ruby для CodeQL находится в бета-версии и может быть изменена. Дополнительные сведения см. в разделе Настройка сканирования кода и в документации по CodeQL. Дополнительные сведения о проверке кода с помощью CodeQL см. в разделе Сведения о проверке кода с помощью CodeQL.

Анализ CodeQL на Python поддерживает дополнительные платформы и может обнаруживать больше потенциальных источников ненадежных пользовательских данных, шагов, через которые эти данные передаются, и потенциально опасных приемников, в которых эти данные могут оказаться. Дополнительные сведения см. в разделе Поддерживаемые языки и платформы в документации по CodeQL.

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

API сканирования кода включает следующие улучшения.

• Оповещения включают fixed_at метку времени, которая является первым случаем, когда оповещение не было обнаружено при анализе. Пользователи могут использовать эти данные, чтобы лучше понять, когда устраняются оповещения сканирования кода.
• Пользователи могут сортировать наиболее важные результаты оповещений с помощью sort и direction в created, updatedили number. Дополнительные сведения см. в статье Проверка кода в документации по REST API.
• Оповещения и ответ конечной точки оповещения включают заголовок Last-Modified . Дополнительные сведения см Last-Modified . в документации по Mozilla.
• Ответы SARIF для анализа сканирования кода включают relatedLocations, которые могут содержать расположения, которые не являются основным расположением оповещения. Пример см. в спецификации SARIF. Дополнительные сведения см. в статье Проверка кода в документации по REST API.
• Объект правила генерации оповещений ответа веб-перехватчика включает help данные и tags . Дополнительные сведения см. в разделе События веб-перехватчика и полезные данные.

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

Пользователи могут отклонять оповещения Dependabot с помощью API GraphQL. Дополнительные сведения см. в разделе "Мутации" в документации по API GraphQL.

Граф зависимостей обнаруживает зависимости Python в репозиториях, использующих диспетчер пакетов Poetry. Зависимости будут обнаружены как в файлах манифеста, так pyproject.toml и poetry.lock в файлах манифеста. Дополнительные сведения см. в разделе Сведения о графе зависимостей.

Разработчики и исследователи безопасности могут использовать CodeQL для создания баз данных и анализа кода на компьютерах на базе микросхем Apple silicon, таких как M1. Интерфейс командной строки CodeQL и расширение VS Code поддерживают apple silicon. Чтобы использовать CodeQL CLI или расширение VS Code в Apple Silicon, пользователям необходимо установить средства командной строки разработчика Xcode и Rosetta 2. Поддержка CodeQL для Apple Silicon находится в бета-версии и может быть изменена.

• Дополнительные сведения о настройке CodeQL CLI на поддерживаемых платформах см. в разделе Использование CodeQL CLI в документации по CodeQL.
• Дополнительные сведения о CodeQL см. в разделе Сведения о CodeQL документации по CodeQL и в разделе Сведения о проверке кода.

Пользователи CodeQL CLI версии 2.7.1 и более поздних версий могут включать справку по запросам в файлы SARIF как Markdown, а текст справки будет отображаться в пользовательском интерфейсе сканирования кода GitHub AE. Пользователи могут включать справку по запросу в качестве файла Markdown с тем же именем, что и соответствующий файл запроса. Например, если файл запроса имеет значение MyCustomQuery.ql, имя файла справки запроса будет иметь значение MyCustomQuery.md. Дополнительные сведения об авторстве справки по запросам для пользовательских запросов CodeQL см. в руководстве по стилю справки по запросам.

• Пользователи, которые не используют GitHub Actions для CI/CD и сканирования кода, должны указать добавление справки по запросу при выполнении codeql database analyze команды, включив --sarif-add-query-help флаг . Дополнительные сведения см. в разделе Анализ баз данных с помощью CodeQL CLI в документации по CodeQL.

Пользователи могут отменить подписку на все репозитории, принадлежащие данному пользователю или организации. Дополнительные сведения см. в разделе Управление подписками.

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

Строка темы для уведомлений по электронной почте о проблемах и запросах на вытягивание включает "(Проблема #ЧИСЛО)" или "(PR #ЧИСЛО)", чтобы помочь пользователям легко различать два типа уведомлений.

Ссылка Просмотр на GitHub в нижней части уведомлений по электронной почте больше не скрыта в Gmail по умолчанию.

Теперь члены организации могут просматривать список владельцев предприятия. Всякий раз, когда член организации сталкивается с запросом связаться с владельцем предприятия, ссылка будет направлять пользователя в список. Список также доступен с помощью объекта API Organization GraphQL в конечной точке enterpriseOwners . Дополнительные сведения см. в разделе Просмотр ролей пользователей в организации.

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

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

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

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

Пользователи могут использовать односимвольный префикс для пользовательских автоматических ссылок. Префиксы автоматического связывания также разрешают .символы , -, _, +``=, :, /и # , а также буквенно-цифровые символы. Дополнительные сведения см. в статье "Настройка автоматических ссылок для ссылок на внешние ресурсы".

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

Улучшен пользовательский интерфейс выпусков, что обеспечивает ясность того, что входит в данный выпуск, и распознавание для участников выпуска. Улучшено разбиение на страницы и доступны новые функции поиска.

Пользователи могут автоматически создавать заметки о выпуске, включающие сводку всех запросов на вытягивание для конкретного выпуска. Дополнительные сведения см. в разделе Автоматически созданные заметки о выпуске.

Пользователи могут просматривать отрисовки файлов Markdown в gist. При создании или редактировании GIST-файла с расширением .mdMarkdown на вкладке Предварительный просмотр или Предварительный просмотр изменений будет отображаться отображение содержимого файла в Markdown. Дополнительные сведения о gist см. в разделе Редактирование и предоставление доступа к содержимому с помощью gist.

Пользователи могут использовать шрифт фиксированной ширины в полях Markdown, например комментарии о проблемах и запросы на вытягивание. Дополнительные сведения см. в разделе Сведения о написании и форматировании на GitHub.

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

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

HTML-ссылки, которые пользователи вставляют в поля Markdown, автоматически преобразуются в ссылки Markdown. Чтобы вставить ссылки HTML в виде обычного текста, нажмите клавиши ⌘/CTRL + SHIFT + v.

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

Пользователи могут задать предпочтительный размер вкладки. Весь код в GitHub AE с вкладками будет отображаться с использованием предпочтительного размера вкладки. Дополнительные сведения см. в разделе Управление предпочтениями отрисовки размера вкладки.

Пользователи могут управлять сочетаниями клавиш с помощью новых параметров специальных возможностей GitHub AE и могут отключить сочетания клавиш, которые используют только одинарные символы, такие как s, g c и . (ключ периода). Дополнительные сведения см. в разделе Управление параметрами специальных возможностей.

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

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

Сканирование кода и проверка секретов теперь общедоступны для GitHub AE. Дополнительные сведения см. в разделах Сведения о проверке кода и Сведения о проверке секретов.

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

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

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

Кроме того, в обзоре безопасности перечислены все оповещения проверки секретов на уровне организации. Аналогичные представления для оповещений Dependabot и проверки кода будут доступны в будущих выпусках. Дополнительные сведения см. в статье "Общие сведения о безопасности".

Граф зависимостей теперь доступен в GitHub AE. Граф зависимостей помогает понять открытый код программного обеспечения, от которое вы зависите, путем анализа манифестов зависимостей, возвращенных в репозитории. Дополнительные сведения см. в разделе Сведения о графе зависимостей.

Оповещения Dependabot теперь могут уведомлять вас об уязвимостях в зависимостях в GitHub AE. Вы можете включить оповещения Dependabot, включив граф зависимостей, включив GitHub Connect и синхронизируя уязвимости из базы данных рекомендаций GitHub. Эта функция находится в бета-версии и может быть изменена. Дополнительные сведения см. в разделе Сведения об оповещениях Dependabot.

После включения оповещений Dependabot участники вашей организации будут получать уведомления при добавлении новой уязвимости, влияющей на их зависимости, в базу данных рекомендаций GitHub или при добавлении уязвимой зависимости в их манифест. Участники могут настраивать параметры уведомлений. Дополнительные сведения см. в разделе Настройка уведомлений для % данных variables.product.prodname_dependabot_alerts %}.

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

• Доступ на чтение во всех репозиториях в организации
• Доступ на запись для всех оповещений системы безопасности в организации
• Доступ к вкладке "Безопасность на уровне организации"
• Доступ на запись в параметрах безопасности на уровне организации
• Доступ на запись к параметрам безопасности на уровне репозитория

Дополнительные сведения см. в статье Управление менеджерами по безопасности в организации.

GitHub AE теперь поддерживает эфемерные средства выполнения (одно задание) и новый workflow_job веб-перехватчик для упрощения средств выполнения автомасштабирования.

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

Вы можете объединить временные средства выполнения с новым workflow_job веб-перехватчиком, чтобы автоматически масштабировать локальные средства выполнения тестов в ответ на запросы заданий от GitHub Actions.

Дополнительные сведения см. в разделах Автомасштабирование с помощью локальных средств выполнения тестов и События и полезные данные веб-перехватчика.

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

Для управления локальными средствами выполнения тестов на уровне предприятия больше не требуется использовать личные маркеры доступа с областью admin:enterprise . Вместо этого можно использовать область для new manage_runners:enterprise ограничения разрешений на маркеры. Маркеры с этой областью могут выполнять проверку подлинности во многих конечных точках REST API для управления локальными средствами выполнения тестов предприятия.

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

Теперь можно задать дату окончания срока действия для новых и существующих личных маркеров доступа. GitHub AE отправит вам сообщение электронной почты, когда придет время продлить срок действия маркера, срок действия которого скоро истечет. Маркеры с истекшим сроком действия можно повторно создать, предоставив вам повторяющийся маркер с теми же свойствами, что и исходный. При использовании маркера с API AE GitHub вы увидите новый заголовок , GitHub-Authentication-Token-Expirationуказывающий дату окончания срока действия маркера. Его можно использовать в скриптах, например для регистрации предупреждающего сообщения по мере приближения даты окончания срока действия. Дополнительные сведения см. в разделах Создание личного маркера доступа и Начало работы с REST API.

Владельцы организации теперь могут экспортировать список людей с доступом к репозиторию в формате CSV. Дополнительные сведения см. в разделе Просмотр пользователей с доступом к репозиторию.

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

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

Дополнительные сведения см. в разделе Управление параметрами проверки кода для вашей команды.

Для пользовательского веб-интерфейса GitHub AE доступны две новые темы.

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

Дополнительные сведения см. в разделе Управление параметрами темы.

Теперь вы можете использовать синтаксис сносок в любом поле Markdown для ссылки на соответствующую информацию, не нарушая поток вашей прозаики. Сноски отображаются в виде надстрочных ссылок. Щелкните сноску, чтобы перейти к ссылке, отображаемой в новом разделе в нижней части документа. Дополнительные сведения см. в разделе Базовый синтаксис записи и форматирования.

Теперь можно переключаться между исходным представлением и отображаемым представлением Markdown в пользовательском веб-интерфейсе, нажав кнопку , чтобы "Отобразить исходный дифф" в верхней части любого файла Markdown. Ранее вам требовалось использовать представление обвинить для связи с конкретными номерами строк в источнике файла Markdown.

GitHub AE теперь автоматически создает оглавление для вики-сайтов на основе заголовков.

GitHub Actions — это мощное и гибкое решение для ci/CD и автоматизации рабочих процессов. Дополнительные сведения см. в разделе Общие сведения о GitHub Actions.

Обратите внимание, что при включении GitHub Actions в ваше предприятие будут отображаться две организации с именем "GitHub Actions" (@actions и @github). Эти организации требуются GitHub Actions. Пользователи с именами @ghost и @actions отображаются в качестве субъектов для создания этих организаций в журнале аудита.

GitHub Packages — это служба размещения пакетов, встроенная интеграция с GitHub Actions, API и веб-перехватчиками. Создайте комплексный рабочий процесс DevOps , который включает в себя код, решения для непрерывной интеграции и развертывания. Во время этой бета-версии GitHub Packages предоставляется бесплатно клиентам GitHub AE.

GitHub Advanced Security доступен в бета-версии и включает как сканирование кода, так и проверку секретов. Во время этой бета-версии функции GitHub Advanced Security бесплатно предлагаются клиентам GitHub AE. Администраторы репозитория и организации могут согласиться на использование GitHub Advanced Security на вкладке Безопасность и анализ в разделе параметров.

Дополнительные сведения о проверке кода и секретах GitHub Advanced Security см. в GitHub AE.

Клиенты, использующие SCIM (система управления междоменной идентификацией), теперь могут синхронизировать группы безопасности в Azure Active Directory с командами GitHub. После связывания команды с группой безопасности членство будет автоматически обновляться в GitHub AE при добавлении пользователя или удалении из назначенной им группы безопасности.

GitHub Списки разрешенных IP-адресов предоставляют возможность фильтрации трафика из указанных администратором диапазонов IP-адресов, определенных нотацией CIDR. Список разрешений определяется на уровне учетной записи предприятия или организации в разделе Параметры > безопасности. Весь трафик, который пытается достичь ресурсов в корпоративной учетной записи и организациях, фильтруется по спискам разрешенных IP-адресов. Эта функция предоставляется в дополнение к возможности запрашивать изменения группы безопасности сети, которые фильтруют трафик для всего клиента GHAE.

Владельцы организации теперь могут отключить публикацию сайтов GitHub Pages из репозиториев в организации. Это не отменит публикацию существующих сайтов.

Репозитории, использующие GitHub Pages, теперь могут выполнять сборку и развертывание из любой ветви.

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

Теперь можно удалить каталог в репозитории со страницы репозитория. При переходе к каталогу новая кнопка kebab рядом с кнопкой "Добавить файл" позволяет удалить каталог.

Теперь проще и быстрее ссылаться на проблемы или запросы на вытягивание с поиском по нескольким словам после "#".

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

Разрешение на один путь к файлу GitHub App теперь может поддерживать до десяти файлов.

При настройке GitHub App url-адрес обратного вызова авторизации является обязательным полем. Теперь мы разрешите интегратору указать несколько URL-адресов обратного вызова. GitHub AE запрещает авторизацию, если URL-адрес обратного вызова из запроса отсутствует в списке.

Новая конечная точка API позволяет обмениваться маркерами пользователя на сервер для маркера пользователя и сервера, ограниченного определенными репозиториями.

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

Теперь поддерживается поток авторизации устройств OAuth . Это позволяет любому клиенту CLI или средству разработчика пройти проверку подлинности с помощью вторичной системы.

Пользователь больше не может удалить свою учетную запись, если включена подготовка SCIM.

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

Существующие репозитории не затрагиваются этими параметрами, и их имя ветви по умолчанию не будет изменено.

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

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

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

GitHub AE теперь может подключаться к Azure Boards.

Заголовки версий отсутствовали в API и теперь имеют значение "GitHub AE".

Ссылки на документацию исправлены.

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

Переход к gist может привести к ошибке 500.

Не удалось сохранить адрес электронной почты или URL-адрес службы поддержки. Теперь он экономит через несколько минут.

Шаблоны запросов на вытягивание на уровне организации применялись не ко всем запросам на вытягивание в организации.