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 и серверные пайплайны.
📚 Читайте также:
- 🔗 Как подготовить WordPress к высокой нагрузке: 100 000 посетителей в день
- 🔗 Переход Apache → Nginx для WordPress: полное руководство и практические примеры
- 🔗 Elasticsearch + WordPress: полное руководство по настройке быстрого поиска (2026)
- 🔗 Оптимизация WooCommerce товары: ускоряем продуктовые страницы за 5 шагов
❓ Часто задаваемые вопросы
Как отключить конкретный Git hook без его удаления?
Достаточно переименовать файл, например, pre-commit.disabled. Git будет игнорировать файл, но вы сможете быстро вернуть его обратно.
Можно ли использовать один hook для нескольких репозиториев?
Да, разместите скрипт в общей директории и в каждом репозитории создайте символьную ссылку на него. Главное – обеспечить одинаковый путь к PHP и другим утилитам.
Что делать, если post‑merge вызывается при каждом pull, даже без конфликтов?
Проверьте условие git rev-parse --verify HEAD в скрипте. Можно добавить проверку, что изменились только файлы composer.json или package.json, иначе скрипт завершается без действий.
Как обеспечить атомарность деплоя при использовании rsync?
Запускайте rsync в два этапа: сначала синхронизируйте в временную папку, затем атомарно переименуйте её в целевую директорию. Это исключит состояние «полу‑обновлённый» сайт.