Git hooks — инструмент, помогающий держать в порядке ваш репозиторий. Можно настроить автоматические правила оформления ваших коммитов. Это в свою очередь позволяет даже новым членам вашей команды соблюдать Code Style, принятый в вашем проекте.
Виды Git hooks
Ранее обсуждали работу с ветками в Git репозиториях, теперь же поговорим о том, как код попадает в общий репозиторий.
При инициализации Git репозитория вы можете найти .git папку, содержащую вспомогательные файлы для гита. Одна из вложенных папок .git/hooks содержит драфты возможных хуков, среди которых:
| Название Git hooks | Назначение хука |
|---|---|
| commit-msg | Хук вызывается перед коммитом. Он может изменять сообщение, а также использоваться, чтобы прервать выполнения коммита, если исходное сообщение не проходит вашу проверку. Хук можно обойти с помощью --no-verify |
| pre-push | Хук выполняется перед пушем. Может быть использован чтобы прервать его. |
| pre-applypatch | Хук выполняется перед применением патчка. Может быть использован чтобы прервать его. |
| prepare-commit-msg | Хук выполняется перед коммитом, после подготовки сообщения по умолчанию. Основная цель - подготовить сообщение. |
| pre-commit | Хук в осноном используется для sanity check вашего кода перед отправкой на code review. |
| pre-rebase | Хук вызывается перед ребейзом. Может быть использован, чтобы прервать его. |
| post-commit | Хук выполняется после завершения коммита. Служит главным образом для уведомлений и не может повлиять на ход коммита. |
Таблица описывает не все, но самые используемые хуки. Полное описание с последовательностью вызовов можно найти в официальной документации.
Примеры Git hooks
Универсальных рецептов какие хуки нужны именно вам не существует, посмотрим какие сценарии можно покрыть с их помощью.
Дополнение commit message
Ветки и тэги в Git могут добавляться и удаляться. Неизменными остаются коммиты и сообщения к ним. Хорошей практикой является добавление вспомогательной информации в commit message. Например префиксом можно поставить номер задачи, которая решается в рамках коммита.
#!/bin/sh # # Automatically adds branch name and branch description to every commit message. # NAME=$(git branch | grep '*' | sed 's/*.*\///') DESCRIPTION=$(git config branch."$NAME".description) echo "$NAME: $(cat $1)" > "$1" if [ -n "$DESCRIPTION" ] then echo "" >> "$1" echo $DESCRIPTION >> "$1" fi echo "" >> "$1" echo "Jira issue" >> "$1" echo "https://TASK_TRACKER_BASE_URL/browse/$NAME" >> "$1"
Данный пример к каждому коммиту добавляет ссылку на внутренний трекер задач и номер текущий ветки. Предположим текущая рабочая ветка feature/DIMLIX-1090, тогда commit message будем выглядеть так:
DIMLIX-1090: My custom commit message entered
Jira issue
https://TASK_TRACKER_BASE_URL/browse/DIMLIX-1090
Таким образом удобно просматривать историю изменений и прикрепленных решаемых задач.
Проверка кода перед коммитом
Возможно, вы не хотите допускать код в ваш репозиторий, который не проходит базовые проверки. Можно создать pre-commit hook, который будет запускать внешнюю проверку и в зависимости от нее давать или нет делать коммит:
#!/bin/bash git stash -q --keep-index echo "Running git pre-commit hook" ./gradlew ktlint RESULT=$? git stash pop -q # return 1 exit code if running checks fails [ $RESULT -ne 0 ] && exit 1 exit 0
Применение хукам ограничено только лишь вашим воображением. Теперь, когда код успешно заливается в ваш репозиторий, самое время поговорить про continuous integration, continuous delivery и удобном деплое ваших приложений.
