GitHub начал сохранять подтверждённого отправителя коммитов

GitHub открыл ограниченное публичное тестирование push attribution для клиентов Enterprise. Платформа будет показывать аутентифицированного пользователя, отправившего коммит, рядом с полями автора и коммитера.

Данные об отправителе коммита в интерфейсе GitHub
Данные об отправителе коммита в интерфейсе GitHub
Изображение из исходного материала

GitHub начал ограниченное публичное тестирование push attribution — функции, которая сохраняет аутентифицированную учётную запись пользователя, отправившего коммит. Идентичность отправителя будет отображаться рядом с уже существующими полями автора и коммитера в интерфейсе GitHub и API.

Обновление предназначено для клиентов GitHub Enterprise. О запуске компания сообщила в GitHub Changelog 12 октября 2026 года. Функция пока не считается общедоступной: для участия в предварительном тестировании нужно обратиться к команде GitHub, отвечающей за аккаунт.

Почему полей автора и коммитера недостаточно

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

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

Новая атрибуция опирается на другой тип данных — аутентифицированную учётную запись, через которую был выполнен push. Она не заменяет автора и коммитера, а добавляется к ним как отдельный сигнал.

Что именно изменится в интерфейсе и API

По заявлению GitHub, сведения об отправителе будут доступны там, где уже отображаются коммиты, а также через API. Это позволит сопоставлять три значения:

  • автора, указанного в метаданных коммита;
  • коммитера;
  • пользователя GitHub, выполнившего push.

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

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

Документация GitHub по работе с коммитами через REST API доступна по адресу: https://docs.github.com/en/rest/commits/commits#get-a-commit

Новое правило для rulesets

Одновременно GitHub добавил правило «Committer must match pusher» — «Коммитер должен совпадать с отправителем». Его можно использовать в rulesets, чтобы ограничить приём коммитов, если указанное в метаданных имя коммитера не соответствует аутентифицированному пользователю, выполнившему push.

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

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

Справочная информация о rulesets опубликована в документации GitHub: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets

Кому доступна функция

Push attribution доступна в ограниченной публичной предварительной версии для клиентов GitHub Enterprise. Для подключения GitHub предлагает обратиться к своей account team и запросить участие в тестировании.

Компания не сообщила в исходном объявлении дату общего запуска, условия расширения доступа или финальную спецификацию функции. Поэтому наличие Enterprise-аккаунта само по себе не означает, что атрибуция уже включена.

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

GitHub подчёркивает, что push attribution должна сделать аудит изменений надёжнее, однако функция не заменяет code review, контроль доступа и другие меры защиты репозитория. До публикации окончательной документации также остаётся неизвестно, насколько широко новое поле будет поддерживаться сторонними инструментами.

Источники