Git hooks — автоматизация и проверки

Логотип Git

Быстрые ссылки

Что такое Git hooks?
Совместное использование хуков
Как использовать хуки

Что такое Git hooks?

Git hooks — это обычные shell-скрипты (чаще всего bash) с определённым именем, расположенные в каталоге

.git/hooks/

Git автоматически вызывает их при выполнении соответствующих действий, что позволяет «подключаться» к рабочему процессу и добавлять свои проверки или автоматические операции.

Репозитории обычно инициализируются с набором примеров хуков (примерные файлы с расширением). Чтобы применить такой пример, достаточно удалить комментарий или сделать файл исполняемым. Заметьте, что в каталоге хуков для каждого имени можно держать только один скрипт — если нужно выполнить несколько задач на одном хук-событии, объединяйте вызовы внутри скрипта или делегируйте их другим скриптам.

Схема работы хуков в локальном репозитории

Что же можно делать с хуками? Практически любую задачу, которую умеет выполнять shell-скрипт. Наиболее частые сценарии:

Автоматический запуск тестов перед коммитом или перед пушем.
Проверка содержимого коммита (поиск конфиденциальных данных, лишних debug-вызовов, неверного форматирования).
Валидация сообщений коммита (например, соблюдение шаблона или наличие задачи в номере).
Автоматический формат кода (pre-commit), генерация файлов, обновление метаданных.

Хуки не заменяют CI/CD: они помогают отлавливать ошибки локально и предотвращать простые промахи до отправки в удалённый репозиторий.

Полезные хуки

pre-commit — выполняется перед созданием коммита (можно отменить коммит)
post-commit — выполняется после коммита
pre-push — выполняется перед пушем на удалённый сервер
post-checkout — после переключения ветки
commit-msg — проверяет текст сообщения коммита

Каждый хук получает аргументы в виде $1, $2 и т.д., доступных внутри shell-скрипта.

Совместное использование Git hooks

По умолчанию каталоги .git/hooks не попадают в историю репозитория, поэтому хуки остаются локальными. Это удобно — каждый разработчик может настроить свои локальные проверки без риска помешать коллегам.

Если нужно распространять набор хуков среди команды, положите их в отслеживаемую папку в репозитории, например

.githooks

и укажите Git использовать эту папку через конфиг:

git config core.hooksPath .githooks

Обратите внимание: это локальная настройка репозитория. Коллегам придётся выполнить ту же команду или добавить инструкцию в README/скрипт установки окружения.

Важно: некоторые инструменты (например, Husky для Node.js) позволяют объявлять хуки в конфигурации проекта, что упрощает настройку всех разработчиков.

Как использовать Git hooks — примеры и рекомендации

Ниже — практические приёмы и готовые сниппеты, которые ускорят внедрение хуков.

Пример: блокировка debug-вызовов в коммите

Если вы хотите запретить попадание вызовов Debug.Log в коммиты, можно проверить staged-изменения:

#!/bin/sh
# Пример pre-commit: запрещаем Debug.Log
if test $(git diff --cached | grep -E "Debug.Log\(" | wc -l) -ne 0; then
  echo "Обнаружены вызовы Debug.Log в индексированных изменениях. Удалите их перед коммитом."
  exit 1
fi

exit 0

Important: Используйте парсинг диффа осторожно — сложные языки и многопоточность могут привести к ложным срабатываниям. Для надёжности применяйте лексический анализатор или специфичный парсер, если нужно.

Пример: запуск тестов перед пушем

В pre-push удобно запускать быстрые тесты или линтер. Пример для .NET:

#!/bin/sh
# pre-push: запускаем модульные тесты
exec dotnet test "./UnitTests/UnitTests.csproj" --filter "Category!=Integration"
if [ $? -ne 0 ]; then
  echo "Тесты должны пройти успешно перед пушем!"
  exit 1
fi

exit 0

Пример конфигурации Husky (Node.js)

Husky позволяет настроить хуки в package.json, чтобы все разработчики получили одинаковое поведение при установке зависимостей:

{
  "husky": {
    "hooks": {
      "pre-commit": "npm test",
      "pre-push": "npm test"
    }
  }
}

Note: Husky и аналогичные инструменты хороши для команд, но не заменяют CI: локальные окружения могут отличаться и давать ложноположительные или ложноотрицательные результаты.

Практические советы по надёжности хуков

Делайте хуки быстрыми. Чем дольше выполняется хук, тем больше раздражения у команды.
Логируйте причину отказа и шаги по исправлению. Сообщение об ошибке должно подсказывать, что делать.
При сложных проверках делегируйте работу отдельным скриптам/утилитам и вызывайте их из хука.
Не храните секреты в хуках. Хуки могут быть выполнены в разных окружениях.
Обновляйте документацию: добавьте в README инструкции по установке core.hooksPath или установочному скрипту.

Альтернативные подходы и когда хуки не подходят

CI/CD: если нужно гарантировать, что тесты выполняются в контролируемом окружении, используйте удалённые пайплайны.
Серверные хуки (server-side hooks): если нужно запретить пуши в удалённый репозиторий по определённым правилам, настройте серверные хуки на Git-сервере.
Pre-receive и update хуки на стороне сервера обеспечат единообразные правила для всех.

Когда хуки бессмысленны:

Когда проверка зависит от окружения, отличного у всех разработчиков.
Когда команда не готова следовать локальным ограничениям — тогда внедряйте правила на CI/сервере.

Безопасность и конфиденциальность

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

Сниппеты и чек-листы (Role-based)

Разделённые чек-листы для ролей ускоряют внедрение.

Для разработчика:

Добавил локальный pre-commit для форматирования кода
Запускаю быстрые тесты перед push
Не коммичу временные debug-вызовы

Для тимлида/релиз-инженера:

Документировал настройку core.hooksPath в README
Предложил server-side проверки в CI для критичных правил
Проверил, что хуки не замедляют рабочий процесс команды

Для DevOps:

Настроил server-side хуки для запрещённых действий
Внедрил мониторинг отказов пушей и ошибок хуков

Критерии приёмки

Хук проходит локальную проверку на 90% тест-кейсов в разработке
Сообщения ошибок содержат шаги для исправления (например, команду для удаления Debug.Log)
Документация включает команду для установки core.hooksPath или автоматическую установку в setup-скрипте

Тест-кейсы и приёмка

Изменения с Debug.Log в staged должны блокироваться pre-commit
Команда dotnet test, вызываемая в pre-push, должна прерывать пуш при неудаче
README содержит инструкцию и не противоречит реальной настройке

Совместимость и миграция

При добавлении .githooks в репозиторий предоставьте скрипт install.sh, который выполнит

git config core.hooksPath .githooks

Для Windows-ориентированных команд используйте скрипты с проверкой окружения и sh или PowerShell версии хуков.

Модель принятия решений (короткая)

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

Краткая библиотека команд (Cheat sheet)

Установить путь к хукам: git config core.hooksPath .githooks
Сделать файл исполняемым: chmod +x .githooks/pre-commit
Локально протестировать хук: .githooks/pre-commit (или sh .githooks/pre-commit)

Иллюстрация сценариев использования хуков

Резюме

Git hooks — лёгкий и гибкий способ автоматизировать локальные проверки и рутинные задачи. Они экономят время и уменьшают количество тривиальных ошибок, но не заменяют CI и серверные проверки. Для совместного использования храните хуки в репозитории и настраивайте core.hooksPath через установочный скрипт или документируйте этот шаг в README.

Ключевые рекомендации: