Хуки в Git — это bash-скрипты, которые запускаются до или после команд Git, например, коммитов и пушей. Они позволяют автоматизировать повторяющиеся действия в вашем репозитории, а также применять фильтры и проверки к рабочему процессу Git.
Что такое Git Hooks?
Итак, Git-хуки идут со специальным именем, в папке:
|
Git будет автоматически вызывать эти функции при выполнении определенных задач, что позволит вам «подключиться» к рабочему процессу Git и изменить его с помощью собственного кода.
Репозитории Git инициализируются с несколькими примерами; чтобы применить их, достаточно откомментировать расширение. Это означает, что у вас будет только один скрипт на один хук. Поэтому если вы хотите выполнять несколько действий, вам нужно будет объединить их или делегировать другим скриптам.
Для чего же их можно использовать? Ну, любая задача, которую может выполнить bash-скрипт, будет работать. Два распространенных варианта использования - автоматическое тестирование и применение фильтров/чеков к исходящим коммитам.
Тесты — важная часть любого рабочего процесса. Хотя Git-хуки абсолютно не заменяют правильного конвейера непрерывной интеграции/непрерывного развертывания (CI/CD), который будет запускать тесты перед проверкой и развертыванием, их локальный запуск поможет вам отловить сбои до того, как они выйдут в свет.
Аналогичным образом, проверка содержимого коммитов для предотвращения распространения нежелательного кода может быть очень полезной, хотя для этого нужно быть достаточно умным, чтобы поймать проблему до того, как она станет проблемой. Если вы часто используете отладочный код, который никогда не должен быть зафиксирован, вы можете проверить это и предотвратить.
Существует множество крючков Git, о которых вы можете прочитать в документации Git'а, но наиболее полезными из них являются:
- pre-commit, post-commit
- pre-push
- post-checkout
- commit-msg
Каждый хук будет принимать аргументы для скрипта, к которым вы можете получить доступ с помощью:
|
,
|
и так далее.
Совместное использование Git Hooks
Git-хуки предназначены только для локального репозитория и не передаются в удаленный. Вы можете установить любые Git-хуки, какие захотите, не затрагивая своих коллег, так что вы можете, например, создать локальную среду тестирования, которая будет зависеть от настроек вашего компьютера при каждом коммите, без каких-либо проблем.
Если же вы хотите поделиться Git-хуками со своей командой, вы можете создать для них новую папку, которая будет отслеживаться в Git, например:
|
и установить в конфигурации значение:
|
|
Как и хуки по умолчанию, эта конфигурация зависит от репозитория, поэтому вашей команде также нужно будет установить это значение.
Как использовать Git Hooks
Как и большинство методов автоматизации, использование Git-хуков во многом зависит от вас и рабочего процесса вашего репозитория, но есть несколько распространенных вариантов использования.
Если вы хотите проверить содержимое коммитов, вы можете использовать git diff для отображения межстрочной разницы, а затем grep для поиска совпадений. В данном случае он блокирует все использование функции Debug.Log, завершая работу с ненулевым кодом:
|
Или вы можете проверить фактическое сообщение о фиксации. Пример pre-push использует аналогичный тест, но вместо него проверяет вывод git rev-list. Он проверяет коммиты, помеченные как незавершённые работы (WIP), и отказывается их проталкивать.
Еще один распространенный вариант использования - автоматический запуск тестов. Вы сами решаете, хотите ли вы, чтобы это происходило при каждом коммите или только перед отправкой изменений на удаленное хранилище.
В любом случае это просто: запустите свою тестовую команду, получите статус выхода последней команды и выбросите ошибку, если она не выполнилась. В этом примере запускаются тесты для приложения .NET:
|
Есть несколько инструментов, которые помогут в этом; Husky легко запустит тесты NodeJS с настройкой конфигурации в package.json, которая будет применяться и ко всем вашим товарищам по команде.
|
Однако это не замена реальным тестам в авторитетном репозитории. Есть сценарии, в которых ваши локальные тесты могут пройти, но удаленные тесты будут неудачными, а именно в случаях, когда вы не ставите все изменения на поток.
