Рабочий процесс GIT для одного разработчика (переход от простого FTP)

Я пытаюсь решить, имеет ли смысл переход на VCS для меня. Я один веб-разработчик в небольшой организации (5 человек). Я думаю о VCS (Git) по следующим причинам: контроль версий, резервное копирование вне сайта, централизованное хранилище кода (можно получить доступ из дома).

На данный момент я работаю на живом сервере вообще. Я подключаюсь к FTP, делаю изменения и сохраняю их, затем загружаю и обновляю. Изменения обычно вносятся в файлы тем / плагинов для CMS (например, concrete5 или Wordpress). Это работает хорошо, но не обеспечивает резервного копирования и контроля версий.

Мне интересно, как лучше интегрировать VCS в эту процедуру. Я хотел бы предусмотреть настройку Git-сервера на веб-сервере компании, но я не понимаю, как отправить изменения в учетные записи клиентов (обычно это VPS на одном и том же сервере) - в данный момент я просто захожу в SFTP с их данными и делаю изменения напрямую.

Я также не уверен, что разумно будет представлять хранилище - получит ли сайт каждого клиента свой собственный?

Любые идеи или опыт будут действительно полезны. Я не думаю, что мне нужна вся мощь Git, но базовый контроль версий и доступ к облаку де-факто были бы действительно полезны.

РЕДАКТИРОВАТЬ: я сузил его до двух вариантов, которые кажутся наиболее разумными. Первый основан на ответе ZweiBlumen , согласно которому изменения вносятся на действующий сервер и передаются оттуда на (внешний) Git-сервер. Это дает преимущество в том, что мой рабочий процесс не сильно изменится (есть дополнительный этап создания коммитов, но в остальном он идентичен).

Второй вариант - работать локально с использованием XAMPP, а затем фиксировать изменения с локального компьютера. Только после запуска сайта я могу загрузить готовую статью на веб-сервер с локального компьютера (сразу после окончательной фиксации в Git). Теоретически это нормально, но если после этого сайт требует внесения поправок, и я делаю их на живом сервере (как я обычно делаю), тогда мне нужно будет вручную скопировать измененные файлы в моем локальном репо, а затем зафиксировать эти изменения в Git сервер. Это кажется чрезмерно сложным и, возможно, слишком большим отклонением от моего текущего рабочего процесса.

Я думаю, что в итоге я попробую вариант № 1 и посмотрю, как у меня получится.

git version-control

— melat0nin
источник

Что нужно помнить о git (или любой другой распределенной VCS), так это то, что все репозитории являются, по крайней мере технически, одноранговыми: ваш локальный репозиторий такой же «реальный», как и на живом сервере или в резервном репозитории. Это ваши рабочие процессы политики, которые дают им структуру - поэтому, если вы действительно хотите продолжать выполнять основную работу на живом сервере, вы можете ...

— прибывающий шторм

Спасибо, это приятно знать. Гибкость, присущая Git, затрудняет разработку исходной точки «лучшей практики» - это сильная сторона POV опытного пользователя, но спорная слабость нубовской!

— melat0nin

Ответы:

То, что я делаю (с Subversion, но буду работать и с Git), это фиксирую все в одном репозитории Subversion, но, очевидно, разделяю на проекты, ветви, теги по мере необходимости. Затем я извлекаю эти репозитории на живой сервер. Таким образом, когда я делаю изменения на своем компьютере разработчика и фиксирую это в хранилище, часто это просто случай обновления извлеченной копии на работающем сервере, чтобы изменения вступили в силу. Дополнительный бонус заключается в том, что, если мне нужно быстро исправить работу на живом сервере, я фиксирую это в хранилище с сервера и обновляю рабочую копию на моем компьютере разработчика.

Я уверен, что есть и другие способы управления этим, но я нахожу это довольно простым, и я нахожусь в точно такой же ситуации, что и вы: один разработчик в небольшой организации (4 человека).

— ZweiBlumen
источник

Спасибо за ваш ответ! Означает ли это, что вы извлекаете моментальный снимок на локальный компьютер, вносите и фиксируете изменения, а затем выполняете запрос извлечения с живого сервера (с помощью SSHing in)? Что если изменение действительно мало? Вы используете локальный веб-сервер для разработки? (Я не мог пройти через этот процесс для простых изменений CSS .. Я бы с ума сошел!)

— melat0nin

Для незначительного изменения CSS я бы сделал изменение непосредственно на сервере, а затем зафиксировал это изменение в хранилище с сервера. Когда мне нужно выполнить более серьезную работу над сайтом, я бы обновлял сайт на своем компьютере разработчика до последней версии сайта из репозитория. Я думаю, что на самом деле не имеет значения, где вы вносите изменения (сервер или компьютер разработчика), пока вы фиксируете это в хранилище.

— ZweiBlumen

Итак, какие инструменты вы используете для этого? FTP для внесения изменений в файл непосредственно на сервере, а затем сеанс SSH, открытый в фоновом режиме, чтобы делать коммиты на сервер Git время от времени?

— melat0nin

Да, вот и все. На самом деле я использую Subversion. У нас есть сайты как на Windows, так и на серверах Linux. В Windows я удаленный рабочий стол на них, внести изменения CSS и зафиксировать, используя TortoiseSVN. В Linux я использую сессию SSH и vim для внесения изменений (но я думаю, вы также можете отправить свои изменения по FTP).

— ZweiBlumen

Я согласился с вашим предложением о редактировании на сервере и последующей фиксации оттуда через SSH, что я делал уже несколько дней. Кажется, работает очень хорошо, спасибо!

— melat0nin

Довольно просто создать post-updateловушку , которая автоматически обновляет (экспорт из- git archiveза соображений безопасности предпочтительнее) каталог данных веб-сервера при переходе к определенной ветке.

Так что где-то с таким хуком нужно создать репозиторий git (из соображений безопасности я бы разместил его на другом сервере, чем в Интернете). Вам, конечно, понадобится тестовый сервер для тестирования больших изменений, которые могут быть либо на вашем локальном компьютере, либо обновлены путем отправки в другую ветку. В любом случае вы можете обойти это для тривиального правописания и CSS-исправлений, просто выполнив commit и push.

— Ян Худек
источник

Я бы следовал этим шагам:

Настройте удаленный сервер с соответствующей парой открытого / секретного ключей для удаленного push / pull
Настройте две ветви тестирования и выпуска
Разрабатывать локально с тестовой средой в ветке тестирования
Когда вы будете счастливы, объединитесь с веткой релиза и отправьте на удаленный сервер.
Подключите удаленный сервер для обновления до последней версии выпуска

Установите один репо на каждый сайт, чтобы они не мешали друг другу. Отдельные ветки позволяют избежать перехода текущей «хорошей» версии к тому, над чем вы сейчас работаете, что может работать, а может и не работать.

— Спенсер Рэтбун
источник

Итак, я правильно понимаю - есть два сервера (1) для Git, (2) живой веб-сервер и один локальный компьютер для разработки. Dev выполняется локально, а затем отправляется на сервер Git, который имеет хук для обновления живого сервера?

— melat0nin

@ melat0nin Это один из способов сделать это. Вы также можете использовать живой сервер с git-сервера как задание cron. Или вы можете иметь 2 машины. Локальная машина разработчика и веб-сервер реального производства. Таким образом, когда вы отправляете репозиторий с компьютера разработчика на рабочий компьютер, он обновляет новейшую ветку релиза.

— Спенсер Ратбун,