Home

Бывает, что в командах тестирования грезят об автоматизации процессов, но почему-то не внедряют даже такие простые вещи как хуки: «Они очень усложняют процесс, и писать их тысячу часов». С этим я категорически не согласен, ведь реализовать хуки очень просто.

Меня зовут Денис Федоров, я тестировщик в команде 2ГИС ПРО, сервисе геоаналитики для бизнеса. Рассказываю, что такое гит-хуки, чем они могут быть полезны и как их можно реализовать у себя. 

Что же такое хуки в Git

Git-хуки — скрипты, которые автоматически запускаются при наступлении определённых событий в жизненном цикле репозитория, таких как commit, push, merge, rebase и другие операции. С их помощью можно автоматизировать различные аспекты рабочего процесса и выполнять необходимые проверки и действия на каждом этапе разработки.

Хуки интегрируются в процесс создания коммита, позволяя автоматизировать и контролировать различные этапы разработки. Они дают разработчикам выполнять определенные действия до и после коммита, что обеспечивает дополнительный контроль и повышает качество кода.

Разберём по этапам. 

Действия пользователя — User Actions

• Шаг 1: подготовка изменений (Stage Changes). На этом этапе разработчик добавляет изменения в индекс (staging area) с помощью команды git add. Это означает, что изменения готовы для коммита.

• Шаг 2: коммит изменений (Commit Changes). Разработчик выполняет команду git commit, чтобы зафиксировать подготовленные изменения в истории проекта.

• Шаг 3: ввод сообщения коммита (Enter Commit Message). После команды git commit требуется ввести сообщение коммита, которое описывает сделанные изменения.

• Шаг 4: завершение процесса (All Done). Коммит завершен, и изменения зафиксированы в истории репозитория.

 Хуки (Hooks):

• Хук до коммита (Pre-Commit Notification). Хук pre-commit запускается сразу после того, как были подготовлены изменения, но до того, как изменения будут зафиксированы. Этот хук обычно используется для проверки кода (например, линтеры), запуска тестов, или других задач, которые должны быть выполнены перед коммитом.

• Хук после коммита (Post-Commit Notification). Хук post-commit запускается после того, как коммит зафиксирован в истории репозитория. Он может использоваться для уведомлений, запуска CI-процессов или других задач, которые необходимо выполнить после того, как изменения зафиксированы.

Польза

Для нашей команды решающим фактором внедрения хуков стало улучшение качества кода. Нам было важно, чтобы линтер пробегал бы не в CI/CD, а до коммита — чтобы не нагружать систему и не тратить лишнее время, а хуки как раз позволяют добавлять линтер перед push. Но у них есть и другие преимущества. Вот самое важное ↓

Автоматизация процессов. Git hooks автоматизируют рутинные задачи, это экономит время и помогает избежать ошибок. Например, Pre-commit hooks проверяют код на стиль или ошибки перед каждым коммитом, а Post-commit hooks автоматически запускают тесты после каждого коммита.

Улучшение качества кода. С помощью хуков можно настроить автоматические проверки качества кода, такие как линтинг для проверки стиля кода, статический анализ для поиска потенциальных ошибок и запуск тестов для проверки функциональности перед отправкой изменений в репозиторий.

Безопасность. Git hooks обеспечивают безопасность, предотвращают некорректные или вредоносные изменения. Например, Pre-receive hooks проверяют коммиты на сервере перед их принятием, а Update hooks — обновления веток.

Поддержка согласованности и стандартов. С помощью Git hooks можно гарантировать, что все разработчики следуют установленным стандартам и процедурам. Так Commit-msg hooks проверяют формат сообщений коммитов на соответствие заданному шаблону, а Prepare-commit-msg hooks автоматически добавляют информацию в сообщение коммита (например, номер задачи из системы управления проектами).

Улучшение рабочего процесса. Git hooks интегрируют различные инструменты и процессы в рабочий процесс. Например, Post-checkout hooks автоматически переключают конфигурации окружения в зависимости от ветки, а Post-merge hooks выполняют необходимые действия после слияния, такие как миграция базы данных.

Виды

Cуществуют два вида хуков:

1. серверный, в этом случае файл един для всех. 

2. клиентский, такие хуки хранятся локально на компьютере разработчика (или любого другого члена команды) и выполняются только для конкретного разработчика, то есть они невидимы для остальных.

Ниже сравнил серверные и клиентские хуки по различным критериям↓

Получается, что серверные хуки обеспечивают централизованный контроль и автоматизацию, что важно для больших команд с высокими требованиями к качеству и безопасности. Но их настройка и обслуживание могут быть сложными, и есть риск влияния на производительность. Клиентские хуки более гибки и удобны для небольших команд или одиночных разработчиков, но они менее надёжны для поддержания общих стандартов и безопасности в крупных проектах.

Учитывая, что наша команда достаточно большая, настройка линтера необходима каждому. Но поскольку настройка локального pre-commit хука для каждого отдельного участника команды занимает много времени, мы выбрали серверные хуки. Такое решение позволяет одному человеку писать и настраивать хук, после чего он доступен всей команде. Это значительно сокращает затраты времени и усилий на внедрение хуков.

Реализация

Ну что ж, перейдём к практической части и реализуем pre-commit хук, который запускает линтер для всех измененных файлов в коммите. В качестве линтера будем использовать pylint (но вообще можно установить совершенно любой).

Шаг первый

Создать или отредактировтаь pre-commit скрипт (он может лежать и называться как угодно). 

Шаг второй 

Написать скрипт, в котором учесть:

• проверку наличия линтера установленного на локальной машине,

• получение списка всех python-файлов, подготовленных для коммита,

• условия выхода, если нет python-файлов,

• и запуск линтера, если файлы есть.

Пример:

# Проверяем наличие pylint
if ! [ -x "$(command -v pylint)" ]; then
  echo 'Error: pylint is not installed.' >&2
  exit 1
fi

# Получение списка всех Python-файлов, подготовленных для коммита
files=$(git diff --cached --name-only --diff-filter=ACM | grep '\.py$')

# Если нет Python-файлов, выход
if [ -z "$files" ]; then
  exit 0
fi

# Запуск pylint для всех подготовленных Python-файлов
pylint $files
if [ $? -ne 0 ]; then
  echo "Pylint found issues. Commit aborted."
  exit 1
fi

Шаг третий

Установить плагин pre-commit и создать файл .pre-commit-config.yaml в коренной папке проекта. Данный плагин помогает запускать много разных скриптов из разных мест в pre-commit, благодаря чему не потребуется в одном файле писать 1000 строк разных скриптов.

В данном файлике надо прописать путь до нашего файла с pre-commit:

repos:

  - repo: local # Указывается local, так как файлик хука у нас находится в репозитории

    hooks:

      - id: custom-hook # Уникальный идентификатор хука

        name: Run my custom hook # Имя хука

        entry: ./pre-commit.sh  # Путь к хуку

                        language: script # указание, что скрипт выполняется как обычный скрипт (script).

Шаг четвертый

Установить хуки из конфига pre-commit

pre-commit install

Эта команда создаст символическую ссылку на наш скрипт pre-commit.sh в директории .git/hooks, чтобы он выполнялся перед каждым коммитом.

Готово! 

Теперь перед каждым коммитом будет запускаться наш хук с линтером. Он предотвратит коммит файлов, не соответствующих требованиям линтера, что поможет избежать запуска неоптимальных пайплайнов и сэкономит время и ресурсы CI/CD системы.

Выводы

Хуки — это простой и очень полезный инструмент. Однако, несмотря на все их преимущества, некоторые специалисты всё ещё опасаются их использовать (мы сначала тоже!). Поэтому под спойлером ниже — ещё раз про основные страхи, связанные с хуками, и как мы сами с ними справлялись.

На этом у меня всё. На тему хуков ещё рекомендую статью Attlassian. Если будут вопросы, то буду рад ответить в комментариях!

Обсудить в форуме