Git: хуки

Хуки хранятся в подкаталоге .git/hooks относительно основного каталога репозитория.

Хуки на стороне клиента запускаются такими операциями как слияние или создание коммита.

На стороне сервера они инициируются сетевыми операциями, такими как получение отправленного коммита.

При инициализации нового репозитория командой git init, Git наполняет каталог примерами скриптов. Все скрипты написаны для shell или Perl, но можно использовать любой другой язык. Главное - правильно именовать файлы.

Примечание: Клиентские хуки не копируются при клонировании и загрузке репозитория. Если вам нужно использовать такие скрипты, то следует использовать серверные хуки.

Клиентские хуки:

pre-commit - запускается до того как вы напечатаете сообщение коммита;
prepare-commit-msg - запускается до вызова редактора сообщения коммита, но после создания стандартного сообщения;
commit-msg - принимает в качестве параметра путь к временному файлу с сообщением коммита;
post-commit - запускается после того, как коммит создан;
pre-rebase - выполняется при попытке перебазирования;
post-rewrite - запускается командами, которые заменяют коммиты (git commit --amend и git rebase);
post-checkout - запускается после успешного выполнения git checkout;
post-merge - запускается после успешного выполнения команды merge;
pre-push - выполняется во время работы команды git push после обновления удалённых ссылок, но до непосредственной отправки данных;
pre-auto-gc - вызывается перед выполнением операции сборки мусора.

Есть еще хуки, которые работают если вы используете обмен патчами (applypatch-msg, pre-applypatch, post-applypatch). Т.к. я этим пока не пользовался, то пока и не изучал.

Серверные хуки:

pre-receive - запускается первым при старте получения данных от клиента;
update - очень похож на pre-receive, но он выполняется для каждой обновляемой ветки;
post-receive - вызывается после окончания всего процесса получения данных.

Серверные хуки недоступны для пользователя, их нельзя получить с сервера при клонировании.

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