Home » Как настроить git push deploy?

Как настроить git push deploy?

devops

Если ты когда-нибудь выкатывал сайт вручную через FTP, ты знаешь, что это боль. Забыл один файл — сайт упал. Не сохранил структуру — привет, баги. А если у тебя команда? Каждый выкладывает “как умеет”. Итог — хаос и потеря контроля.

Сегодня расскажу, как настроить автоматический деплой сайта на хостинг через git push. Это не только удобно, но и спасает от кучи ошибок. Статья для всех: SEO-шников, вебмастеров, дорвейщиков, владельцев сайтов и просто тех, кто хочет навести порядок в выкладке проектов.

Зачем нужен git push deploy?

Автоматизация: Выкладываешь сайт одной командой, без ручных операций.
Контроль версий: Любой откат — в пару кликов, видно кто, когда и что выкладывал.
Безопасность: Нет FTP-логинов на каждом компе, меньше шансов что-то сломать.
Скорость: Деплой за секунды. Не надо гонять мегабайты по FTP или SCP.
Легко интегрировать CI/CD: Можно подключить тесты, сборку, минификацию и т.д.

Общая схема git push deploy

У тебя есть репозиторий (например, на GitHub, GitLab, Bitbucket или свой локальный).
На сервере (хостинге) настраивается git-репозиторий, который принимает push.
В post-receive hook прописываешь команды, которые выкладывают код в нужную папку.
Делаешь git push production master — и сайт обновился.

Выглядит просто, но есть нюансы! Давай разберёмся на практике.

Пошаговая инструкция: как настроить git push deploy

1. Подготовь сервер (или хостинг)

Нужен SSH-доступ к серверу или VPS. Если у тебя обычный shared-хостинг без SSH — этот способ не подойдёт (но есть альтернативы, расскажу ниже).

Убедись, что установлен git на сервере:

sudo apt update sudo apt install git

2. Создай bare-репозиторий на сервере

Залогинься на сервер по SSH и создай папку для bare-репозитория (это репозиторий без рабочей копии, только для приёма push):

mkdir -p ~/repos/mysite.git cd ~/repos/mysite.git git init --bare

3. Пропиши post-receive hook

Этот скрипт будет запускаться после каждого push. Он выкладывает изменения в папку с сайтом.

cd ~/repos/mysite.git/hooks nano post-receive

Пример содержимого (замени /var/www/mysite на свою рабочую папку):

#!/bin/bash GIT_WORK_TREE=/var/www/mysite git checkout -f

Сделай скрипт исполняемым:

chmod +x post-receive

4. Добавь remote на локальной машине

На своем компьютере, в папке проекта, добавь новый remote:

git remote add production ssh://[email protected]/~/repos/mysite.git

(Замени [email protected] на свои данные.)

5. Деплой!

Теперь всё просто:

git push production master

Код выкатывается на сервер автоматически. Можно настроить любые ветки, например, main или develop.

Практические советы и примеры

Плюсы и минусы подхода

Плюсы:
- Всё под контролем — история изменений, откаты, кто что залил.
- Легко интегрировать тесты, сборку, деплой статики и т.д.
- Нет ручных ошибок (не зальёшь не тот файл, не забудешь что-то).
- Работает даже на самых простых VPS и выделенных серверах.
Минусы:
- Требуется SSH-доступ (на обычных хостингах — не всегда есть).
- Нужно немного разбираться в git и bash-скриптах.
- Если выкатка идёт прямо в /var/www — можно случайно сломать сайт (лучше выкатывать в отдельную папку и переключать симлинк).
- Нет “отката” деплоя — если что-то пошло не так, надо руками возвращать предыдущую версию.

Кейс: позитивный опыт

У меня был проект на Laravel, который выкладывался на VPS через git push. Команда из 3-х человек, каждый делал git push production master — и сайт обновлялся за 3 секунды. Никто не парился с FTP, не забывал миграции. В post-receive hook добавили composer install и php artisan migrate — всё автоматом.

Кейс: негативный опыт

Один раз на shared-хостинге попробовали сделать git push deploy через panel-хаков — мучились с правами, кривыми путями, отсутствием SSH. В итоге плюнули и вернулись к FTP. Поэтому — всегда проверяй, что твой хостинг поддерживает SSH и git!

Варианты для shared-хостинга (без SSH)

GitHub Actions + FTP/SFTP Deploy:
Можно настроить GitHub Actions (или GitLab CI), чтобы после push в репозиторий происходила выгрузка файлов по FTP/SFTP на хостинг. Минус — нет контроля версий на сервере, но всё равно лучше, чем руками!

Пример: https://github.com/marketplace/actions/ftp-deploy
Скрипты на локальной машине:
Можно сделать bash-скрипт, который после git push сам отправляет изменения по FTP/SFTP.
Плагины для CMS:
Например, для WordPress есть плагины, которые позволяют тянуть код из git (WP Pusher, Gitium).

Расширенные фишки

В post-receive hook можно добавить автосборку фронта (npm run build), деплой статики, уведомления в Telegram и т.д.
Можно выкатывать не в прод, а в staging — отдельную ветку для тестов.
Для безопасности — выкатывай не в корень сайта, а в отдельную папку, и делай симлинк на актуальную версию (rollbacks — за 1 секунду).
Можно настроить деплой на несколько серверов (production, backup, dev).

Частые ошибки и мифы

Ошибка: Репозиторий выкатывается прямо в папку с сайтом — если что-то сломалось, сайт падает.
Решение: Деплой в отдельную папку, переключай симлинк (ln -s).
Ошибка: Не учитываются файлы, которых нет в git (например, картинки, загруженные через админку).
Решение: Храни user-content отдельно, не трогай его при деплое.
Миф: Git push deploy — это сложно.
Факт: После первой настройки — проще не бывает. Всё автоматом.
Ошибка: Не настроены права на файлы/папки — сайт не работает.
Решение: В post-receive добавь команды chown и chmod при необходимости.

Бонус: Советы по выбору хостинга для git push deploy

Ищи хостинг с SSH-доступом (VPS, cloud, выделенные сервера).
Проверь, что установлен git (или можно поставить).
Узнай, не запрещены ли кастомные скрипты (post-receive).
На shared-хостинге ищи опции “Git Deploy”, “Git Integration” — у некоторых хостеров это есть.
Рекомендую: DigitalOcean, Timeweb VPS, REG.RU VPS, Hetzner Cloud.

Заключение — стоит ли заморачиваться?

Если ты устал выкладывать сайты вручную, боишься потерять файлы или хочешь работать в команде — git push deploy это must-have. Это не только экономит время, но и делает выкладку сайта безопасной и предсказуемой. Даже если ты дорвейщик или SEO-шник, который клепает сотни сайтов — автоматизация деплоя сэкономит тебе кучу нервов.

Рекомендую попробовать на тестовом проекте. Если не хватает SSH — смотри в сторону CI/CD (GitHub Actions, GitLab CI) или ищи хостинг с поддержкой git. Не бойся автоматизировать рутину — это твоя инвестиция в спокойствие и порядок!

Если есть вопросы или хочется кейсов под твой стек — пиши в комментарии или в телегу, помогу разобраться!

Официальные ссылки:
Git Hooks (официальная документация)
GitHub Actions: FTP Deploy
GitHub Actions Docs

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

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