Git-деплой — способ публиковать сайт на сервере прямо из репозитория, без ручной загрузки файлов по FTP. Разработчик делает commit и push, после чего сервер сам забирает изменения и обновляет рабочую версию проекта. На каждом релизе это экономит десятки минут, а заодно снижает риск забыть какой-нибудь файл.
Что такое Git-деплой и какие у него преимущества
Git-деплой работает через хук. Хостинг следит за событиями в репозитории и при каждом push в указанную ветку автоматически запускает обновление.
Раньше обычный сценарий выглядел примерно так: разработчик меняет код локально, собирает архив, запускает FileZilla и вручную перезаливает десятки файлов. А потом пытается вспомнить, что именно изменилось. Достаточно пропустить один файл, и сайт падает уже в проде. Git-деплой этот этап попросту убирает.
- Все изменения остаются в истории коммитов. Видно, кто, когда и что поменял.
- Предыдущую версию можно вернуть за секунды, достаточно перейти к нужному коммиту.
- Несколько разработчиков спокойно работают параллельно и не перезаписывают вручную одни и те же файлы.
- Автодеплой подключается к CI/CD, поэтому тесты можно запустить еще до публикации.
| Параметр | Ручная загрузка (FTP/SFTP) | Деплой через Git |
|---|---|---|
| Скорость обновления | 5-15 минут вручную | 15-60 секунд автоматически |
| Риск человеческой ошибки | высокий | низкий |
| История изменений | отсутствует | полная, по коммитам |
| Откат к прошлой версии | сложно, нужен бэкап | git checkout за секунды |
| Совместная работа | конфликты файлов | ветки и merge |
По моим наблюдениям, примерно семь из десяти небольших студийных проектов до сих пор загружают на сервер вручную через FileZilla. Пока проект маленький, схема терпимая. Но команда растет, файлов становится больше, и ручная заливка начинает откровенно тормозить работу.
Как настроить автодеплой на примере популярного провайдера
На настройку автодеплоя обычно уходит 10-15 минут. Нужно привязать репозиторий, выбрать рабочую ветку и указать команды сборки.
Возьмем Timeweb Cloud. Здесь Git-деплой встроен в панель управления облачным сервером, поэтому вручную настраивать вебхуки не придется, все делается через готовый интерфейс.
- Открываем в панели хостинга настройки проекта и находим подключение репозитория.
- Затем авторизуемся через GitHub, GitLab или Bitbucket. Хостинг получит доступ к списку репозиториев.
- Нужный репозиторий выбран, теперь указываем ветку для продакшена, чаще всего main или master.
- Если проект требует компиляции, прописываем команды сборки: npm install, npm run build и путь к папке со статикой.
- Сохраняем параметры. Хостинг сам создаст webhook в репозитории и будет вызывать его при каждом push.
- Наконец, делаем тестовый commit и открываем лог деплоя в панели. Там видно, какие команды отработали и сколько времени заняла сборка.
У большинства провайдеров для разработчиков схема похожая: Render, Railway, VK Cloud, Beget с поддержкой Git. Панели выглядят по-разному, но механика та же, webhook запускает скрипт сборки на сервере.
Работа с ветками и тестовыми окружениями
Нормальная схема веток дает проверить изменения в отдельном окружении и не трогать боевой сайт, пока код не готов. Это тот случай, когда лишние пять минут на настройку потом здорово берегут нервы.
Самый практичный вариант — держать хотя бы две ветки: main для продакшена и develop или staging для тестов. Хостинг настраивают так, чтобы push в staging разворачивал копию сайта на отдельном поддомене, а push в main обновлял основной домен.
- В main хранится стабильный код. Сюда пушат после ревью и проверки.
- Develop используют как рабочую ветку, в нее попадают фичи от участников команды.
- Для конкретных задач удобно заводить feature-ветки, особенно если в команде три человека и больше. Соло-разработчику такая схема часто ни к чему.
Тестовое окружение лучше сделать максимально похожим на прод: та же версия PHP или Node.js, те же переменные окружения, кроме секретных ключей платежных систем, естественно. Иначе получится классика: на staging все работает, а в проде падает из-за различий в версиях.
С базой данных отдельная история. Автодеплой обновляет код, но сам по себе БД не меняет. Миграции запускают отдельным шагом в скрипте сборки либо вручную после деплоя. Если этого не сделать, структура таблиц и код довольно быстро разойдутся.
Типичные ошибки при первой настройке Git-деплоя
На старте проблемы чаще вызывает не Git, а серверное окружение и мелочи в конфигурации. Причем мелочи вполне способны положить весь сайт.
- Секреты попадают в открытый репозиторий. Пароли от БД и API-ключи оказываются в коде, а затем остаются в истории коммитов, откуда удалить их уже непросто. Используйте .env и .gitignore с первого дня.
- Деплой идет сразу в прод, без staging. Одна опечатка в конфиге, и сайт недоступен живым пользователям. Тестовое окружение здесь работает как обычная страховка.
- Зависимости забыли установить. Папки node_modules или vendor правильно добавляют в .gitignore, но команду установки зависимостей на сервере не прописывают. В результате сборка падает из-за отсутствующего модуля.
- Права доступа выставлены неверно. После деплоя папки с загрузками или кешем порой остаются без права на запись, и сайт перестает сохранять пользовательские файлы.
- Логи деплоя никто не смотрит. Автодеплой настроили и забыли проверить, срабатывает ли webhook вообще. Потом неделю правят код, который физически не публикуется. Такое, увы, бывает регулярно.
И еще раз про миграции базы, тут действительно легко потерять время. Если структура БД меняется в коде, а сама база автоматически не обновляется, разработчики порой неделями ищут баги. Хотя причина простая: схема и код рассинхронизировались. Если после деплоя проект ведет себя странно, сначала проверьте именно это.
Частые вопросы
Классический shared-хостинг с ограниченным доступом к SSH часто не поддерживает Git-деплой напрямую. Для этой схемы нужен VPS, облачный сервер или специализированная платформа с встроенной поддержкой репозиториев. Многие провайдеры сейчас добавляют эту функцию даже в бюджетные тарифы.
Хорошие системы деплоя используют атомарное переключение: новая версия собирается в отдельной папке и подменяет старую только после успешной сборки. Если сборка упала, пользователи продолжают видеть предыдущую рабочую версию сайта. Стоит заранее проверить у своего провайдера, реализован ли у него такой механизм.
Да, большинство современных панелей хостинга позволяют подключить репозиторий и настроить автодеплой полностью через веб-интерфейс. SSH обычно нужен только для более тонкой настройки скриптов сборки или отладки нестандартных ситуаций.
Достаточно сделать git revert нужного коммита или переключить ветку деплоя на предыдущий стабильный тег и снова запустить публикацию. Это займет меньше минуты против часов восстановления из бэкапа при ручной загрузке файлов.
Да, но код и база данных обновляются раздельно: сам Git отвечает только за файлы темы, плагинов и ядра, а изменения в БД нужно переносить через миграции или отдельные SQL-скрипты. Это стоит продумать заранее, иначе структура кода и базы быстро разойдутся.
