Git-хуки

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

Каждый репозиторий получает встроенные хуки, когда вы используете команду git init . Когда репозиторий инициализируется, вы получаете скрытый каталог .git , а внутри него находится каталог с именем hooks, который будет содержать все ваши крючки. Откройте любой доступный репозиторий git и используйте ls -a , чтобы увидеть скрытый каталог, а затем откройте его в своем любимом редакторе кода.

Для начала вы увидите кучу файлов с расширениями .sample . Это именно то, что они говорят, примеры сценариев, которые вы могли бы использовать в своих проектах. Файлы названы в соответствии с хуком, на котором они работают. Таким образом post-commit.sample запускается на хуке post-commit .

Вы можете использовать практически любой язык для написания хука. Файл анализируется в соответствии с нотацией Шебанга в верхней части файла. Если вы хотите использовать узел, вы должны использовать #! /usr/bindi/env node #! /usr/bindi/env node , и ваш файл будет проанализирован как файл узла.

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

Типы хуков Git

Фиксация хуков рабочего процесса

pre-commit запускается еще до того, как вы вводите сообщение о коммите, и его можно обойти с помощью git commit --no-verify .

prepare-commit-msg можно использовать для редактирования сообщения по умолчанию, которое вы видите в своем сообщении фиксации. Используйте его, чтобы дать разработчикам инструкции о том, какой тип сообщения фиксации они должны оставлять. Его также можно использовать для автоматизации содержимого того места, где сообщение автоматически генерируется для вас, например, для слияния или для автоматического добавления номера проблемы к вашему сообщению о коммите.

commit-msg можно использовать для проверки сообщения фиксации для вашего проекта. Возможно, вы не хотите, чтобы кто-либо мог вставить сообщение коммита, в котором просто говорится «работа с пробелами». Вы можете использовать этот хук, чтобы обнаружить наличие пробелов в словах, а затем выйти и предоставить пользователю предупреждение о том, что ему нужно лучшее сообщение фиксации.

post-commit запускается после всех хуков фиксации выше. Это наиболее полезно для уведомления о том, что фиксация была сделана.

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

post-checkout запускается после успешного выполнения команды git checkout. Если у вас есть набор больших файлов, используемых на сайте, но вы не хотите, чтобы они находились в системе управления версиями, вы можете использовать эту команду для перемещения файлов за вас.

pre-push запускается во время команды git push до того, как какие-либо объекты будут переданы в удаленный репозиторий.

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

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

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

Многие из вышеперечисленных хуков можно настроить для работы только на определенных ветках. Это может означать, что вы используете хук post-receive только тогда, когда кто-то отправил код в основную ветку, которая должна быть готова к развертыванию. Список разработчиков может быть уведомлен о проверке кода, а затем его развертывании. Таким образом, вы всегда будете иметь 2 группы глаз при развертывании, что может означать обнаружение ошибок, которые может легко пропустить один разработчик.

Я пропустил некоторые доступные хуки, потому что никогда не видел необходимости их использовать. Один набор ловушек, о которых я не говорил, — это ловушки рабочего процесса электронной почты. Если вы не принимаете исправления для своего кода по электронной почте, они, скорее всего, вам никогда не понадобятся. Вы можете найти все доступные хуки в документации.

На практике крючки, которые я использовал больше всего:

• предварительная фиксация
• предварительный толчок
• сообщение фиксации
• предварительно получить
• после фиксации
• после получения

Теперь давайте сделаем что-нибудь с этими крючками.

Активация плагина WordPress с помощью WP Cli и Git Hooks

Для одного клиентского проекта в этом году я добавлял магазин и еще выполнял несколько задач на основном сайте. Это означало, что на основном сайте не были установлены или активированы какие-либо из наших плагинов WooCommerce. Мне нужно было разработать магазин WooCommerce в одной ветке, и только после того, как я был готов запустить все это вживую, я захотел переместить WooCommerce в основную.

Для начала нам понадобится новая ветка с именем store. Мы можем получить это, используя git checkout -b store . Это создает новую ветку и проверяет ее для нас. Теперь подготовим крючок.

Сначала нам нужно создать хук post-checkout с помощью этой команды touch .git/hooks/post-checkout .

Далее нам нужно сделать его исполняемым. Мы можем сделать это с помощью команды chmod из терминала chmod +x .git/hooks/post-checkout .

Теперь откройте файл в выбранном вами редакторе кода и скопируйте приведенный ниже код в файл post-checkout .

#! /bin/bash

wp plugin activate woocommerce

echo "activated WooCommerce"

wp plugin activate automatewoo

echo "activated AutomateWoo"

Вы можете продемонстрировать это, перейдя на любую ветку через терминал. Вы должны увидеть две строки, говорящие о том, что WooCommerce и AutomateWoo были активированы. Мы знаем, что это работает, но это не совсем то, что нам нужно, потому что плагины будут включаться каждый раз, когда мы переходим на любую ветку.

Чего мы действительно хотим, так это включать их, когда мы переходим в нашу ветку магазина, а затем выключать их, когда мы находимся в нашей основной ветке. Для этого нам понадобится хук, чтобы определить, к какой ветке мы относимся. Замените содержимое post-checkout кодом ниже.

#! /bin/bash

oldrev=$1
newrev=$2

branch_name="(git symbolic-ref HEAD 2>/dev/null)"

if [ "refs/head/store" = "$branch_name" ];then
wp plugin activate woocommerce
echo "activated Woo"

wp plugin activate automatewoo
echo "activated AutomateWoo"
fi

if [ "refs/head/main" = "$branch_name" ];then
wp plugin deactivate woocommerce
echo "deactivated Woo"

wp plugin deactivate automatewoo
echo "deactivated AutomateWoo"
fi

Этот код начинается с назначения ветки, которую мы проверяем, переменной branch_name . Тогда у нас есть два оператора if. Первый проверяет, не перешли ли мы в ветку магазина. Если у нас есть, он использует WP CLI для активации WooCommerce и AutomateWoo.

Следующий оператор if проверяет, находимся ли мы в основной ветке. Если да, он деактивирует плагины с WP CLI и сообщит нам об этом в терминале.

Управление рабочими процессами Git с помощью Git Hooks

В предыдущем посте о Git я говорил о различных рабочих процессах Git. Один из очень распространенных вариантов использования хуков — не дать кому-либо зафиксировать код непосредственно в основной ветке. Вы можете использовать хук, чтобы убедиться, что весь код из другой ветки объединен с основной.

Начните с переименования pre-commit.sample в pre-commit а затем сделайте его исполняемым, как я описал выше. Затем возьмите приведенный ниже код и используйте его в файле предварительной фиксации.

#! /bin/bash

username=$GIT_AUTHOR_NAME
branch="$(git symbolic-ref HEAD 2>/dev/null)"

if [ "$branch" = "refs/heads/main" ]; then
echo "WHOA that was '"${branch}"' you should not do that. Stop doing silly stuff and create your own branch and merge it."
exit 1 # if you remove this it won't block the commit but it will send the message to slack
fi

Это проверяет, находимся ли мы в основной ветке, и если да, то фиксация останавливается. Затем он печатает напоминание пользователю о том, что он не должен делать коммиты непосредственно в основной ветке.

Помните, что многие места меняются на main в качестве своей ветки. Для более старых проектов здесь может потребоваться master , если они не обновлены.

Вы даже можете сделать еще один шаг и использовать cURL для доступа к API приложения чата, а затем публично жаловаться, что кто-то пытался зафиксировать в main.

Единственным ограничением git hooks является ваше воображение. Вы можете использовать их, чтобы остановить кого-то от фиксации, если в их коде присутствует TODO, или чтобы убрать пробелы в конце файла.

Если у вас есть какая-то часть вашего рабочего процесса, которая является постоянным камнем преткновения, посмотрите на крючки, чтобы автоматизировать ее, чтобы вам не приходилось вспоминать.