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

Question

[max_web]

Приветствую знатоки!
Хочу перевести разработку/поддержку сайтов на git, но тут есть проблема почти все сайты клиентов находятся на обычных хостингах, где есть доступ по ftp, и работать так не очень удобно. Давно хотел начать использовать git но как это сделать с такими сайтами не знаю, проблема еще в том что над ними могут работать несколько человек и при заливке надо учитывать возможные изменения уже на хостинге.
Т.е. слить все к себе создать репозиторий на github или bitbucket особо нет проблем, но вот как заливать все на хостинг пока для меня непонятно.

Answer 1

[Евгений Вольф]

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

Передельно просто. Рецепт такой:
1. Берёте любой, можно самый дешевый VPS (если своего сервера нет)
2. Настраиваете там GIT'репозитории в нужном количестве
3. В каждый репозиторий, кладёте скрипт-хук, который будет выгружать изменившиеся файлы на нужны FTP-сервер (судя по ссылкам выше, подобные решения есть уже или в готовом или в полу-готовом виде).

То есть, Вам навсего нужно ознакомиться с механизмом "хуков" гита, как мне видится. И можно ещё пожалуй, ознакомиться с FTP-клиентами запускаемыми из консоли, или механизмом монтирования FTP как файловой системы... Вариантов много, Вам нужно просто выбрать.

Comments

[Adamos]

Ну да, "передельно просто" - затирать файлы на сайте своими версиями, и никаких коллизий.
Если их сдуру еще кто-то когда-то правил - не мои проблемы... да?

[Евгений Вольф]

Adamos: не понимаю сути проблемы. Ровно с такой же вероятностью и аналогичным образом, можно затереть файлы на сайте, если бы там вместо ФТП стоял GIT-репозиторий. Если у Вас в мастер-ветке какие-то коллизии - то это уже проблема выходящая за рамки изначально поставленного вопроса.

Answer 2

[lexnekr]

Удивительно, но некоторые "обычные хостинги" (например, beget, не рекламирую) умеют использовать git. Как правило делается это по запросу.
Уточните у техподдержки хостера.

Comments

[Михаил]

+1

Answer 3

[Павел Белоусов]

Описанная проблема - это только вершина айсберга.
Вам необходимо поменять подход к самой разработке.
Пока клиент будет лазить в код и на FTP — вы не сможете нормально работать с git.
Пока сайт клиента будет на шаред-хостинге — вы не сможете нормально работать с git.

Начнутся проблемы с расхождением версий на ftp и вашем локальном окружении и репозитории, начнутся конфликты при миграции БД.

В общем то попробуйте, поймёте, что что-то не то и в итоге придёте к нормальному решению :)

Comments

[Сергей]

Что Вы имеете ввиду под нормальным решением?

[Павел Белоусов]

Сергей: Как правило нормальное решение - это итог договорённостей с клиентом, учитывающий его и ваши желания и ожидания, и подбор оптимального способа деплоя, сборки и т.п.

Но в общем случае это:
- разработка только на машине разработчика, никаких ftp и т.п.
- все изменения на продt только через гит.

Answer 4

[Алексей Сундуков]

git не поддерживает работу по ftp протоколу. Поэтому в изложенном контексте работа должна строиться так:

1) Заводим пустой репозиторий в битбакете или гитхабе (напоминаю, что в гитхабе приватные репозитории платные).
2) Клонируем его себе локально в папку Х.
3) Настраиваем ftp клиент (например FileZilla) на эту папку Х и папку на хостинге.
4) Заливаем в хостинга файлы сайты.
5) Добавляем в git появившиеся файлы (git add).
6) Коммитим из (git commit -a).
7) Отправляем изменения на удаленный репозиторий (битбакет/гитхаб, git push).

Периодически по ftp сливаем файлы в локальную папку, через git diff смотрим изменения. Если они легитимные, то делаем git commit. Если нет, откатываем нужные (git checkout имя_файла). Снова фиксируем (git commit), отправляем в удаленные репозиторий (git push), перезаливаем из локальной папки.

Comments

[Сергей]

Работать с настроенным git можно из командной строки или придется FileZill- использовать при каждой передаче двнных?

[Алексей Сундуков]

Сергей: С гитом работаем на локальной машине. Когда изменения внесены, через FileZill копируем файлы назад на хостинг. Если на сайте что-то изменилось, то нужно через FileZill файлы сайта скопировать себе и снова работать через гит. Т.е. постоянное копирование файлов туда-сюда придется делать постоянно. Это имеет смысл только если это сайт клиента у которого в принципе нет ssh доступа на хостинг (шаред хостинг) и приходится работать с тем, что есть. Но при малейшей возможности нужно с таких хостеров уходить. Сейчас вдс стоит на уровне шареда и в наши дни нет ни какого смысла использовать шаред если есть хоть какие-то технические знания.

[Сергей]

Я просто что-то смутно помню про remote ветки и путь по типу ftp://YourFtpUser%40YourDomain.com:YourFtpUserPass...
Там, вроде, можно было clone и fetch делать, но push нельзя. Короче, ничего не изменилось, по ходу...

Answer 5

[Марат Мхитарян]

Есть много ci/cd сервисов. Например buddy.works там просто нужно указать ваш гит репо и что выгружать при каждом комммите в мастер на ftp сервер.

Это все бесплатно если деплои непотребляют много ресурсов. Вы вмегда можете поднять Jenkins усебя на raspberry pi или vps.

Answer 6

[zooks]

На хостинге должен быть установлен git. Заливается также - через clone.

Answer 7

[Пума Тайланд]

Сливаешь себе репо и заливаешь по фтп

Answer 8

[Kjuri]

Если не смогли найти варианты в интернете до сих пор - то лучше не лезьте.
А так вариантов хватает.
Простейший - создал репозиторий на гит/битбакет, настроил доступы и т.д. клонировал-залил по фтп
Посложнее - хуки + сервисы непрерывной интеграции.
Ну и еще сложнее - хуки, настройки на сервере и SSH

Answer 9

[Игорь Билецкий]

https://deploybot.com/
Плюсы:
1. Есть всё что нужно для эффективного деплоймента (выгрузка по ftp, sftp, atomic sftp...)
2. Возможность предварительной сборки фронтенда (gulp, grunt... ) на отдельном docker контейнере
3. Можно указывать паттерны исключаемых файлов или папок к выгрузке
4. Нотифткация через разные сервисы (на пример slack) о статусе выгрузки

Минус: сервис платный (15 баксов в месяц на 10 проектов)