Как правильно редактировать сайт с с помощью git?

Question

[Вячеслав Климов]

Вот есть сайт. Он на хосте со своим доменом в своем серверном окружении и т.п. То есть в достоверно рабочем виде существует в одном месте в одном экземпляре.
Обычно когда мне надо внести какие то правки в код сайта я подцепляюсь по ftp вношу правку, тут же в браузере проверяю работоспособность, при необходимости снова правлю 1-2-10-50... раз пока нужный результат не достигнут. после чего просто заканчиваю работу. Это быстро и просто, и результат виден сразу.
Этот подход имеет недостаток отсутствия контроля версий. Необходимо использовать гит. Но как это делать?
Вот я ставлю себе гит, создаю репозиторий на гитхабе, создаю локальную копию у себя на компе. Теперь могу править на компе и хранить на гитхабе, а потом с гитхаба заливать файлы на хост. Но проверка кода на локальной машине получается теперь в слепую, без быстрой проверки, а заливка правки на сайт становится долгой и нудной операцией.
Прихожу к выводу, что я что-то очень неправильно понимаю в подходе к этой работе, но какого то мануала по этой задаче найти так и не удалось. Все обьяснения крутятся между локалькой и гитхабом при разработке приложений.

Comments

[Сергей delphinpro]

Что мешает развернуть полноценную локальную копию проекта, всю разработку вести на ней, пушить в репу, а на, сервере только деплоить из репозитория?

[Вячеслав Климов]

Это само собой напрашивается. Поэтому и обозначил про единственный достоверно рабочий.
А по делу, если с вордпрессом это вполне прокатывает, то к примеру с Битриксом (а с ним мне часто приходится работать) окружение локально настроить та еще задача. А кроме того в том же битриксе многие настройки сохраняются в файлы, идет постоянная подкачка файлов из 1С баз, так что боевой сайт и локальная копия будут быстро расходится...
Но вообще скорее всего с таким костылем и буду работать.

[YMakeev]

Не страшно "боевую" копию редактировать на живую?
А если что-то пойдет не так?
Бекап есть?

[Вячеслав Климов]

YMakeev, Страшно, а что делать?
На самом деле не все так плохо, файловая копия как правило есть на локалке. На сервере соответственно серверный бекап. Работа через ftp. В ide есть стрелочка "назад". Ну и php это "язык созданный умирать", а значит подвешивание машины не грозит. Так, что падение скрипта, выбрасывание warning, e_notice и т.п. не повод для расстройства, а рабочий момент исправляемый за секунды. К тому же и это бывает редко, все же не в слепую работаю.
Но все это не отменяет потребности в документированном контроле версий.

Answer 1

[Дмитрий Шицков]

Могу предложить такие варианты:

• Сделать так, чтобы не приходилось проверять так тщательно после обновления на удалённом сервере. Настройте свое локальное окружение для лучшего соответствия.
  
• Заведите на сервер поддомен, типа dev.mysite.org и проверяйте все там как удобно, прежде чем обновлять прод
  
• Не используйте git на prod. Версионирование нужно для кода, а не сервера. Туда можно хоть архивом лить.
  

Ну и как комбо вариант, начать использовать ci/cd, тот же Travis. Обновилась ветка с подготовлены релизом - автоматом вылился на сервер по scp/sftp с адресом-поддоменом. Все устроило? Мердж в мастер и автоматом(на самом деле, лучше вручную или с ограничением по git tag) поехало на прод.

Answer 2

[YMakeev]

Вячеслав Климов продолжу тут, в виде ответа.
Я понял ваши варианты по бекапам и причинам редактирования основного сайта...

С некоторых пор, я люблю использовать "копию продакшен окружения".
В вашем случае это может быть поддомен основного сайта или просто тестовый домен из бесплатного пула.
Вот на нем все править, добивать ся работоспособности, а после всех тестов и апрувов - лить на основной.
Дмитрий Шицков , советует правильные мысли, попробуйте такой вариант.
Если же вы фанат локальной разработки - то поднимите 1-2 докер контейнера, создайте в них свое окружение и используйте в работе (для удобства разработки код может быть в томах :) )