В течение многих месяцев я пытался спланировать хорошую структуру проекта для использования контроля версий git для разработки веб-сайтов WordPress, которая не жертвует возможностью обновления ядра и плагинов через панель управления WP, не требует нестандартной структуры каталогов (wp -контент за пределами родительской папки WP), что позволяет легко управлять и развертывать целые веб-сайты. Я читал о подмодулях, поддеревьях, вложенных репозиториях и т. Д., И мне все еще трудно совместить все это и выбрать правильную стратегию.
Вот что я думаю прямо сейчас, с моими мыслями о том, как я буду обращаться с git-репозиториями в скобках.
root (main project repo)
|-- wordpress (public git repo added as subtree)
| |-- wp-content
| | |-- plugins
| | | |-- my-custom-plugin (git repo added as subtree)
| | | |-- other-plugin-with-git-repo (git repo added as subtree)
| | | +-- other-plugin-without-git-repo (ignored/untracked)
| | |-- themes
| | | |-- my-custom-theme (git repo added as subtree)
| | | |-- other-theme-with-git-repo (git repo added as subtree)
| | | +-- other-theme-without-git-repo (ignored/untracked)
| | +-- uploads (ignored/untracked)
| |-- wp-admin
| +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt
Это оставляет меня с несколькими проблемами / вопросами;
Автоматические обновления; Мне нравится новая функция автообновлений, она потенциально может сэкономить много времени и усилий для поддержания моих сайтов в обновленном и безопасном состоянии, но, похоже, это мешает отслеживать изменения кода с помощью git. Есть ли способ отследить изменения в моем коде, позволяя ядру WordPress автоматически обновляться?
Помешает ли наличие поддеревьев в репозитории ядра WordPress, чтобы я не использовал git для слияния новых обновлений ядра или не отправлял свои изменения обратно в репозиторий ядра WordPress (если я когда-нибудь решу, что хочу стать основным спонсором)?
Для плагинов, у которых нет общедоступного репозитория git, их полное игнорирование создает проблему невозможности быстрого клонирования всего сайта на новом сервере без копирования файлов на сервер вручную. Это также вызывает проблему, если я хочу внести изменения в код этого плагина, эти изменения не отслеживаются и могут быть легко потеряны при обновлении плагина.
Итак, подведем итог: что такое хорошая настройка git + WordPress, которая позволяет избежать этих проблем? Буду признателен за ваши отзывы о моей предложенной структуре проекта. Любой способ, которым вы можете помочь мне улучшить это, будет высоко ценится!
PS, если есть лучший форум для этой дискуссии, пожалуйста, укажите мне там.
источник
install.php
подпрограммы или чего-то подобного и использовать обычную механику обновления оттуда. Стек Composer может очень хорошо обрабатывать обновления в абстрактном виде, но он зависит от качества используемых вами пакетов и таких вещей, как проксирование официальных репозиториев WP, так как оно еще не вполне готово.Вы можете взглянуть на эту проблему и эту проблему.
Также взгляните на файлы README в каждом репо:
На основании вышеприведенных репозиториев, в качестве другого примера настройки Git / WP, я создал это . Я решил использовать символические ссылки для тем (я пытаюсь охватить это в моем README ).
Я вроде как в той же лодке с автоматическими обновлениями ... Мой план состоял в том, чтобы вручную обновлять подмодуль WP, когда обновления происходят. Я думаю, что альтернатива, теоретически (мне еще предстоит проверить себя), позволить субмодулю обновляться самостоятельно для незначительных обновлений (для этого есть настройка WP), а затем делать
git
принудительную / перезагрузку подмодуля, когда выходят крупные обновления ( может быть, один из ответов здесь может быть чем-то полезен ... конечно, я думаю, что при обновлении до следующего основного выпуска хотелось бы указать целевой тег WP.Стоит отметить, что если WP видит
.git
пути, он автоматически отключает автоматические обновления. Для получения дополнительной информации см .:Другие ссылки по теме:
Май 2015 обновление
Я создал этот репозиторий, который является быстрым способом запуска проектов WordPress. Мой последний подход заключается в том, чтобы управлять версиями только темы. Другими словами, я устанавливаю WP локально (используя установку в вышеупомянутом репозитории) и на производстве, затем я изменяю конфигурационный файл в каждой системе и
git
извлекаю свои темы для получения функционального сайта.источник
Этот тип разработки относится к категории «не так просто и требует специального рабочего процесса, который может занять много времени, чтобы быть довольным».
Я нахожу поддеревья, субмодули или вложенные репозитории, огромную боль в заднице.
Некоторые мысли (отслеживать все).
add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );
Безопасный метод через ручные коммиты + электронная почта:
Вы можете использовать промежуточный сервер и уведомления об обновлениях по электронной почте, фиксировать обновления и отправлять их на работающий сервер, на котором отключены автоматические обновления.
Это также позволяет вам копировать / вставлять папки для ваших собственных репозиториев по желанию, что часто является тем, как я это делаю. Это также облегчает клонирование / уничтожение нескольких промежуточных серверов, git действительно вступает в силу с помощью этого метода, поскольку он распространяется.
Недостаток: копирование / вставка папок, управление.
Авто метод
Установите скрипт сборки (Phing, Ant, Bash, Capistrano и т. Д.) И некоторый пользовательский код, который будет выполнять git add + commit при применении обновления и отправлять его на работающий сервер. Вы также можете разделить плагины / репозитории тем, а затем заставить скрипт скомпилировать / переместить / что угодно их, и / или использовать Composer в миксе.
Подобная автоматизация рабочего процесса также имеет тенденцию быть негибкой и стоит того, только если вы видите реальную потребность в затраченном времени.
Недостаток: негибкий, требует времени для создания.
Git не должен использоваться для резервного копирования, и, вообще говоря, вам не нужно клонировать историю коммитов WP.
источник
После некоторых размышлений, поскольку я определенно хочу воспользоваться преимуществами собственных обновлений WP, чтобы избавить себя от лишней работы, нет смысла отслеживать что-либо, что WP обновит с помощью git. Вот пересмотренная идея.
Конечно, тогда я теряю возможность отслеживать, какие плагины и темы являются частью проекта из VCS, но мне это действительно нужно только для целей резервного копирования, и я все равно буду использовать какую-то обычную систему резервного копирования.
Итак, единственное, чего мне действительно не хватает, так это возможности легко развернуть весь стек на разных серверах без использования FTP для ручного копирования всего этого. У кого-нибудь есть мысли по этому поводу?
источник
Хорошо, смотрю выступление Марка Джакита здесь , может быть, я не на том пути. Вот еще один удар, который отслеживает все.
Я предполагаю, что основным недостатком этого является наличие пользовательского каталога содержимого, что в прошлом вызывало у меня проблемы с плохо написанными плагинами и темами, которые не могли найти каталог содержимого.
источник