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.