Рабочий процесс Git с WordPress - Localhost to Live

Question

У меня есть простой, но общий вопрос рабочего процесса WordPress.

Текущий рабочий процесс

1. Я все разрабатываю локально
2. FTP-файлы (и дамп базы данных) до сервера, чтобы показать клиенту
3. Внести запрошенные изменения локально
4. FTP-файлы (и дамп базы данных) снова запустить сервер
5. Больше локальных правок
6. FTP (и дамп базы данных) снова увеличить
7. Сполосните и повторите

Это стало чудовищной болью.Должен быть лучший способ

Подозреваемый рабочий процесс Git

1. Локальная копия будет моим 'master'
2. Push-файлами вверхкуда-то
3. 'Потяните' файлы из этого места посередине на мой живой / тестовый сервер

Я думаю, что у меня есть представление о том, как это должно быть концептуально, но я нене знаю, как это должно быть практически сделано.Должен ли я использовать частный репозиторий Github в середине?Есть ли способ, чтобы мой Live-сайт «извлекал» прямо из моего репозитория localhost?

Извинения, если это кажется элементарным или уже забитым, но я искал и не нашел базового «Этокак должен выглядеть ваш рабочий процесс ».

С благодарностью!

Терри

Answer 1

Похоже, вы вообще не используете контроль версий.Это хорошая идея, что вы собираетесь начать.Я просто конвертировал из SVN в Git, и я вроде как делаю то, что вы делаете на более грандиозном уровне.Давайте начнем с ваших целей:

1. Получить управление версиями
2. Установить какое-либо развертывание в сети через Git
3. Хостинг управления версиями удаленно

Люди скажут вам, что Git не является инструментом веб-развертывания - они могут быть правы, но пока он работает нормально для меня, и я сделал нечто подобное.К счастью для вас, я практиковался в установке Wordpress - вот шаги, которые я предпринял.

1. Получил все с установкой Git и установил, насколько клиент идет.
2. Скачал последнюю версиюWordpress в ванильной установке.
3. git init базовая установка без изменений
4. Разветвление мастера на "dev" и "live"
5. Работа локально, фиксация в"dev", затем, как только изменения сделаны, объединены в живую.

Теперь я вернулся к созданию виртуальной машины gitolite и использовал ее в качестве своего хоста - это эффективнозаменил github в вашем примере.Я думаю, вы знаете ценность удаленного репозитория - я бы определенно следовал этому маршруту.

Я собираюсь вернуться на секунду на шаг 2 моих рекомендаций.Вы должны держать ванильную версию Wordpress на главном, чтобы вы могли обновить ядро ​​и посмотреть, как оно работает с вашим пользовательским кодом, вместо того, чтобы обновлять ядро ​​на чем-то вроде одной из ваших веток и всего ломающегося.Это было довольно удобно для меня и кое-что, что я определенно буду использовать в более крупных проектах, таких как Magento.

Хорошо, вернемся к развертыванию.Вы можете разместить git-клиент на своем веб-сервере и получить его pull из своей ветки в рабочем процессе - но вы должны принять некоторые особые соображения по планированию.Ваши prod-файлы, скорее всего, будут отличаться от ваших dev-файлов в определенных местах, особенно в конфигурации (база данных и т. Д.) - вам нужно убедиться, что эти файлы находятся в .gitignore, поэтому вы не набираете dev конфигурации в вашей prod среде.

Я в основном суммировал то, что мне сказали люди, когда я начал работать над этим, поэтому я надеюсь, что это поможет.Опять же, я просто немного прошел мимо вас, поэтому, если у кого-то есть какие-либо исправления / оптимизации, пожалуйста, не стесняйтесь комментировать.

Answer 2

Я начинаю настраивать такой рабочий процесс для Wordpress. Он уже работает для нескольких других веб-проектов.

Я использую gitolite (https://github.com/sitaramc/gitolite/wiki/) инструмент для управления пустыми репозиториями (репозиториями без локальной проверки) в центральном местоположении, а затем запускаю ловушку обновления в gitolite, когда ветка выталкивается из места разработки.

Затем этот ssh подключается к работающему серверу (или к учетной записи клиента или какому-либо другому) с общим закрытым ключом, хранящимся на сервере развертывания, и выполняет git pull из public_html или любого места, где вы работаете с установкой Wordpress.

Это делается с помощью доступной только для чтения записи в файле конфигурации gitolite, которая является conf / gitolite.conf в локальном хранилище конфигурации. (Gitolite использует git-репозиторий для управления своими конфигурационными файлами)

repo wp-versions
  RW+ = tmzt
  R = server1
  R = server2

Первый - это мой первичный открытый ключ, который хранится в том же хранилище, что и keydir / tmzt.pub (в том же формате, что и .ssh / authorized_keys). Два других являются живыми веб-серверами, которые будут иметь доступ только для чтения к хранилищу. Добавьте три ключа в keydir и убедитесь, что вы зафиксировали и нажали. Изменения будут автоматически внесены в установку gitolite. (Ключи сервера совместно используются несколькими пользователями и копируются в файл .ssh / id_rsa каждого пользователя, но при желании это могут быть данные www).

RW + означает, что мой основной пользователь имеет права на чтение, запись и может обновлять ветки без ускоренной пересылки (полезно для отмены коммитов на сервере).