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

Я работаю с Wordpress, хотя это подходит для большинства сценариев разработки сайтов. Я хочу управлять установкой сайта с помощью git-репозитория, а также управлять различными плагинами WP, плагинами jQuery и другими частями кода в отдельных репозиториях, которые могут быть легко извлечены/заимствованы из их внешних источников. Кажется, что все достаточно просто, пока вы не посмотрите на детали...

Критерии

Критерий "Подпапки" Папка для каждого плагина не должна быть привязана к корневой папке его исходного репозитория. Многие репозитории имеют несколько вложенных папок, таких как "my-repo-name/...", "dev/", "test/", "src/", где содержимое последней является тем, что требуется. Это важно для сохранения чистоты URL-адресов ссылок и минимизации общедоступного мусора.

"No Proxys" критерий. Идеальное решение не требует дополнительных промежуточных веток или репо. Внесение изменений во внешний источник плагина должно быть простым и не требовать множества промежуточных слияний/внесений.

Критерий "Реальные файлы" В идеале внешнее репо для всего сайта должно фактически содержать файлы подрепо плагинов (т.е. никаких "подмодулей"). Хотя меня можно переубедить в этом...

"Publishing" criterion Он должен хорошо работать с rsync и/или git push'ing на живой сервер

Я рассмотрел эти пять решений

Git Submodules Достаточно прост для внесения изменений и push/pulling, но субмодули не работают по критериям "Subfolders" и "Real File"

Git read-... tree/subtree merge Решает проблему "Реальных файлов", а read-tree действительно позволяет ссылаться на подпапку ветки, но когда я сделал это и попытался слить изменения на master обратно вверх по течению, Git не запомнил, что они пришли из подпапки и слил всю структуру master в ветку ext libs tracking. ...так что FAIL по этому критерию.

Расширение поддерева Apenwarrs (здесь) Отлично подходит для критерия "Реальные файлы" и довольно просто для проталкивания/выталкивания, пока вы не захотите применить правило "Вложенные папки". В лучшем случае это требует промежуточных веток, где вы выделяете нужную вам папку из удалённой ветки отслеживания, а затем добавляете её в качестве поддерева в главную ветку. Мне не очень повезло со слиянием/толчком изменений на master обратно в исходное репо. Я все еще думаю, что здесь может быть возможность...

Символьные ссылки с внешним репо Отличное решение, пока GIT не перестал следовать симлинкам. Теперь он не работает по критериям "Реальные файлы" и "Публикация"

Вложенные репо Где-то я видел ответ SO, где если вы явно git add папку, которая содержит другое репо и включаете косую черту, git НЕ будет подмодулировать его, а вместо этого будет отслеживать отдельные файлы. Это казалось многообещающим, но это не работает по критерию "Подпапки".

Что дальше?

Я видел упоминания о "разреженной проверке" - или, возможно, о чём-то, связанном с обрезкой ветвей. Я надеюсь избежать решения, которое включает сценарии оболочки или является настолько сложным, что требует от меня заново изучать его каждый раз (нечасто), когда я вношу изменения в плагин. Это должно быть проще, чем поддерживать отдельную репозиторию для каждого плагина и копировать туда и обратно из основной установки CMS.

Наверняка у кого-то есть простой функциональный способ заставить работать этот распространенный сценарий разработчиков? Заранее спасибо за помощь...