Git hooks WordPress: автоматизация проверок и деплоя в 5 шагов

Введение: почему стоит автоматизировать деплой WordPress?

Каждый разработчик, работающий с WordPress, сталкивается с рутиной: проверка кода, обновление зависимостей, загрузка файлов на продакшн‑сервер. Ошибки в этом процессе могут привести к падению сайта, особенно при высокой нагрузке. Подготовка WordPress к 100 000 посещений в день показывает, насколько важна стабильность. Git hooks позволяют встроить автоматические проверки непосредственно в процесс коммита и слияния, избавив от ручных действий.

Настройка pre‑commit: статический анализ кода

Установка PHP_CodeSniffer и WP Coding Standards

Для начала необходимо установить инструменты, которые будут проверять соответствие кода стандартам WordPress.

composer require --dev "squizlabs/php_codesniffer=*" composer require --dev "wp-coding-standards/wpcs=*" phpcs --config-set installed_paths vendor/wp-coding-standards/wpcs phpcs -i

После установки phpcs будет выводить список доступных стандартов, среди которых WordPress и WordPress-Core.

Создание скрипта pre‑commit

В каталоге репозитория создаём файл .git/hooks/pre-commit и делаем его исполняемым.

#!/bin/sh # Проверяем только staged файлы PHP FILES=$(git diff --cached --name-only --diff-filter=ACM | grep ".php$") if [ -z "$FILES" ]; then exit 0 fi # Запускаем PHPCS phpcs --standard=WordPress $FILES RESULT=$? if [ $RESULT -ne 0 ]; then echo "nPHPCS обнаружил ошибки. Коммит отменён." exit 1 fi exit 0

Теперь каждый git commit будет останавливать процесс, если код не проходит проверку.

Post‑merge: автоматическое обновление зависимостей и сборка фронтенда

Composer install и npm run build

После слияния ветки в main часто требуется установить новые пакеты и собрать ассеты. Для этого создаём hook post-merge.

#!/bin/sh # Устанавливаем PHP‑зависимости if [ -f composer.json ]; then composer install --no-dev --optimize-autoloader fi # Сборка фронтенда, если есть package.json if [ -f package.json ]; then npm ci && npm run build fi exit 0

Hook гарантирует, что локальная среда всегда синхронизирована с последними изменениями. Подробнее о том, как собрать assets, читайте в статье Elasticsearch + WordPress: настройка быстрого поиска.

Синхронизация с сервером: post‑receive и rsync

Настройка удалённого репозитория на продакшн‑сервере

Самый надёжный способ деплоя – «bare‑репозиторий» на сервере, который срабатывает после получения пуша.

# На сервере создаём bare‑репозиторий mkdir -p /var/www/wordpress.git && cd /var/www/wordpress.git git init --bare # Добавляем hook post-receive cat > hooks/post-receive <<'EOF' #!/bin/sh TARGET=/var/www/html GIT_DIR=$(pwd) # Обновляем рабочую копию git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f # Синхронизируем файлы через rsync (исключаем.git) rsync -avz --delete --exclude='.git' $TARGET/ user@cdn.example.com:/var/www/cdn EOF chmod +x hooks/post-receive

После этого достаточно выполнить git push production main, и сайт будет обновлён без вмешательства человека. Для ускорения доставки статических файлов см. руководство BunnyCDN + WordPress.

Best practices: интеграция с CI/CD и безопасность

  • Не храните секретные ключи в репозитории – используйте .env и dotenv на сервере.
  • Запускайте те же проверки в CI (GitHub Actions, GitLab CI) – это гарантирует, что каждый пайплайн проходит одинаковый набор тестов.
  • Ограничьте доступ к hook‑скриптам только пользователям с правом записи в репозиторий.
  • Регулярно обновляйте зависимости: composer update и npm audit fix.

Если планируете мигрировать серверную часть, обратите внимание на статью Переход Apache → Nginx для WordPress. Совместное использование Nginx, Git hooks и CDN даст вам максимальную производительность.

Заключение

Git hooks – простой, но мощный инструмент, позволяющий автоматизировать проверку кода, обновление зависимостей и деплой WordPress‑проекта. Внедрив pre‑commit, post‑merge и post‑receive, вы уменьшите количество человеческих ошибок, ускорите релизы и получите более предсказуемый процесс разработки. Начните с малого: добавьте проверку PHPCS, а затем постепенно расширяйте набор скриптов, интегрируя их в CI/CD и серверные пайплайны.

❓ Часто задаваемые вопросы

Как отключить конкретный Git hook без его удаления?

Достаточно переименовать файл, например, pre-commit.disabled. Git будет игнорировать файл, но вы сможете быстро вернуть его обратно.

Можно ли использовать один hook для нескольких репозиториев?

Да, разместите скрипт в общей директории и в каждом репозитории создайте символьную ссылку на него. Главное – обеспечить одинаковый путь к PHP и другим утилитам.

Что делать, если post‑merge вызывается при каждом pull, даже без конфликтов?

Проверьте условие git rev-parse --verify HEAD в скрипте. Можно добавить проверку, что изменились только файлы composer.json или package.json, иначе скрипт завершается без действий.

Как обеспечить атомарность деплоя при использовании rsync?

Запускайте rsync в два этапа: сначала синхронизируйте в временную папку, затем атомарно переименуйте её в целевую директорию. Это исключит состояние «полу‑обновлённый» сайт.