git hooks — сценарии, выполняемые на стороне клиента или на стороне сервера. Файлы хуков пишутся на любом скриптовом языке и размещаются в каталоге ./git/hooks, они обязательно должны иметь бит исполнения.
Git hooks: что это и как использовать
Любой хук — просто сценарий, который возвращает код ответа. Если код ответа отличен от нуля (0 означает, что выполнение успешно) — произойдет прерывание и желаемое действие, такое как commit, не выполнится.
Хуки копируются в любой репозиторий при его инициализации с git init
Они могут использоваться на стороне сервера и на стороне клиента
Полная информация как всегда есть в документации
man githooks
Хуки пользователя размещаются в ~/.git/hooks
cd .git/hooks && ls -ls
applypatch-msg.sample post-update.sample pre-commit.sample pre-push.sample update.sample
commit-msg.sample pre-applypatch.sample prepare-commit-msg.sample pre-rebase.sample
Для всех сценариев, имеющихся по умолчанию задано расширение .sample, если переименовать файл убрав расширение и дать права на исполнение хук станет активным.
mv pre-commit.sample pre-commit
chmod +x pre-commit
Тут хук, который активировали сейчас является самым базовым, он будет выполняться до того как будет выполнен коммит каждый раз когда разработчик вводит соответствующую команду
pre-commit проверяет есть ли среди файлов, которые коммитятся такие, имя которых находится не в кодировке ASCII. Если такие есть результат выполнения bash скрипта pre-commit будет 1, и коммита не произойдет. Вместо него в консоль будет выведено сообщение об ошибке поясняющее причины возникших трудностей.
Создаются хуки на пользовательской стороне для собственного удобства, их всегда можно обойти выполнив команду с ключом —no-verify
git commit —no-verify
Git hooks на стороне сервера
На сервере — в удаленном приватном репозитории (или на github) также имеются хуки они размещаются в КАТАЛОГ_ПРОЕКТА/hooks/
Их предназначение обычно в другом, такие хуки используют для ограничения доступа. Если в предыдущем случае коммит бы просто не выполнился — если ограничить список разработчиков, которые могут коммитить изменения со стороны сервера — коммит будет выполняться, но сервер отклонит попытку внесения изменений.
Таким образом удобно разделять права к репозиторию или запрещать определенным разработчикам вносить изменения в ветку master.