Git, суб-repos и внешние библиотеки для веб-разработки - лучшая стратегия раз и навсегда?

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

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

Критерии

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

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

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

Критерий "Публикация" Он должен хорошо работать с rsync и/или Git нажатием на живой сервер

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

Git Субмодули Достаточно просто для внесения изменений и нажатия/вытягивания, но подмодули выходят из строя на критериях "Подпапки" и "Реальный файл"

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

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

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

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

Что дальше?

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

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

Ответ 1

Очевидно, вы об этом подумали, и я всего лишь новичок в git, но моим первым инстинктом было бы добавить .gitignore в каталог плагинов и иметь каждый плагин с его собственным git repo. Вы можете сделать то же самое для тем. Поэтому я предполагаю, что это скорее вопрос, чем ответ - почему бы не использовать этот простой подход?

Ответ 2

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

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

Repos
    - Utilities
        - Util repo1
        - Util repo2
    - Common
        - Lib repo1
        - Lib repo2
    - Projects
        - Client1
            - Git repo1
            - Git repo2
        - Client2 repo
        - Client3
        ...

У нас возникла проблема с ручным запуском/вытягиванием/фиксацией каждого репозитория, который стал кошмаром.

Итак, мы написали небольшую служебную программу, которая может выполнять операции push, pull, commit, tag, remote diff и diff Git в нескольких папках за раз, а также одновременно создавать несколько файлов решений VS, Он также проверит в подпапках для репозиториев.

Мы используем его в течение некоторого времени, и он отлично подходит для нас. Вы можете проверить это здесь: Gitter.7z

Откройте файл ReadMe.html, чтобы узнать, как его использовать. Надеюсь, что это поможет, дайте мне знать.