git merge --verify-signatures: как проверить подпись

Что именно проверяется при merge

Опция `--verify-signatures` валидирует подпись tip-коммита ветки, которую вы собираетесь влить. Если подпись не проходит проверку по trust model Git/GPG, merge прерывается. Это важное ограничение: наличие одного подписанного tip не доказывает, что все предыдущие commits были подписаны. Для строгой цепочки нужна отдельная политика и, возможно, серверное требование подписанных commits.

Совет: Сначала протестируйте `git verify-commit` на известном подписанном commit.

Как включить проверку

1. Убедитесь, что локальная система подписи настроена и Git умеет проверять ключи нужных участников.
2. Сначала вручную выполните `git verify-commit <sha>` для примера ожидаемой подписи и доверия.
3. Попробуйте `git merge --verify-signatures feature`, чтобы увидеть поведение до изменения глобальной конфигурации.
4. Если правило подходит workflow, задайте `git config merge.verifySignatures true` локально или на нужном уровне.
5. Проверьте сценарий с неподписанным тестовым tip, чтобы команда понимала ожидаемое сообщение об отказе.

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

Криптографически корректная подпись и доверенный автор — не всегда одно и то же. Git использует доступную систему проверки и её trust model, поэтому на новой машине тот же commit может не пройти без нужного публичного ключа или настроенного доверия. В CI желательно заранее управлять keyring/SSH signing configuration предсказуемо. Если проект использует GitHub verified commits, локальная GPG/SSH-проверка и серверная метка — связанные, но не идентичные механизмы.

Предупреждение: Не воспринимайте подписанный tip как доказательство подписи каждого commit в ветке.

Перед обязательным rollout

• определить поддерживаемый тип подписи;
• распространить публичные ключи/доверие;
• проверить CI и локальные машины;
• документировать процедуру при ротации ключа.

Что именно проверяется

Проверка относится к подписи tip-коммита присоединяемой ветки, а не автоматически ко всем коммитам её истории. Если политика требует подтверждения каждой подписи, это нужно обеспечивать отдельными правилами и проверками, а `--verify-signatures` рассматривать как один контроль на этапе merge.

Где проверка подписи особенно уместна

`--verify-signatures` полезен как дополнительный барьер перед слиянием ветки, если команда договорилась принимать только подписанные tip-коммиты от доверенных ключей. Но доверие к ключу и политика проекта остаются отдельными задачами. Проверяйте, какой ключ считается допустимым, и не трактуйте успешную проверку одного tip-коммита как криптографическую аттестацию всей истории ветки.

Пример безопасного merge на release-ветку

Перед вливанием `release-candidate` вы выполняете merge с `--verify-signatures`. Если tip подписан доверенным release-ключом, Git продолжает обычную merge-процедуру. Если подписи нет или проверка не проходит, история не меняется от этой команды, и вы сначала выясняете происхождение commit вместо отключения проверки ради скорости.

Важно: Не отключайте проверку в CI «на один раз» без понятного процесса исключений и аудита.

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

Криптографически корректная подпись и доверенный автор — не всегда одно и то же. Git использует доступную систему проверки и её trust model, поэтому на новой машине тот же commit может не пройти без нужного публичного ключа или настроенного доверия. В CI желательно заранее управлять keyring/SSH signing configuration предсказуемо. Если проект использует GitHub verified commits, локальная GPG/SSH-проверка и серверная метка — связанные, но не идентичные механизмы.

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

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

• git-merge Documentation
• Git merge options